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PREFATORY  NOTE 

Faced  with  the  enormous  responsibility  of  training  soldiers  to  defeat  an  adversary  who  will  both 
outnumber  and  outgun  them  on  the  battlefield,  the  Army  training  and  research  communities  have  adopted 
various  training  initiatives.  Among  these  is  the  development  of  computer  based  and  computer  assisted  battle 
simulations.  Since  a  battle  simulation  can  serve  as  a  cost-effective  bridge  between  classroom  and  field  training, 
the  development  of  battle  simulations  is  expected  to  continue  well  into  the  future.  One  problem  the  Army 
training  and  research  community  has  experienced  in  the  past  has  been  the  conveyance  of  user  requirements  to 
system  developers,  perhaps  the  most  critical  step  in  the  development  of  any  automated  system.  Battle  simulation 
requirements  that  are  poorly  stated  or  that  are  not  stated  at  all  can  result  in  products  that  fail  to  attend  to 
required  training  objectives. 

The  purpose  of  this  paper  is  to  document  an  approach  that  can  be  applied  by  the  training  and  research 
community  to  convey  to  the  system  developer  how  a  new  battle  simulation  must  function  in  order  to  play  an 
effective  role  in  training.  To  accomplish  this  purpose,  the  functional  requirements  for  an  actual  battle  simulation 
are  presented.  These  requirements  were  prepared  by  HumRRO  during  the  development  of  SIMCAT 
(SIMuladon  in  Combined  Arms  Training),  a  battle  simulation  being  developed  for  the  U.S.  Army  Research 
Institute  for  the  Behavioral  and  Social  Sciences  (ART).  The  approach  to  the  development,  format,  content,  and 
purpose  of  the  functional  requirements  for  SIMCAT  is  presented  in  detail.  It  is  intended  that  the  contents  of  this 
paper  serve  as  a  model  for  the  development  of  functional  requirements  for  future  battle  simulations  so  that  they 
can  be  accurately  communicated  to  the  actual  system  developers. 

It  should  be  noted  that  no  classified  information  was  referenced  or  in  any  other  way  used  to  develop  this 
document  AS  A  RESULT,  NO  CLASSIFIED  INFORMATION  IS  CONTAINED  IN  THIS  PAPER. 
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INTRODUCTION 


AirLand  Battle  doctrine  advocates  increased  decentralization  of  command  and  control  during  combat  It  is 
anticipated  that  platoon  leaders,  company  commanders,  and  other  leaders  of  small  combat  units  w01  have 
greater  latitude  in  exercising  initiative  during  military  operations  than  such  leaders  have  had  in  the  past  This 
expectation  is,  in  part,  the  result  of  a  need  to  maintain  greater  dispersion  among  units  as  a  defense  against  the 
increased  lethality  of  opposition  force  (OPFOR)  weapon  systems,  especially  NBC  (Nuclear,  Biological  and 
Chemical)  weapons,  and  as  a  consequence  of  OPFOR  interference  in  battlefield  command  and  control.  It  is 
also  due,  in  part,  to  the  need  for  commanders  at  all  levels  to  exploit  existing  opportunities  in  order  to 
compensate  for  OPFOR  superiority  in  manpower  and  weapon  systems.  These  commanders  must  be  able  to 
deviate  from  initial  plans  as  events  unfold  while  they  fulfill  their  functions  in  the  overall  mission  in  order  to 
ensure  the  success  of  that  mission.  In  short,  leaders  must  not  only  maintain  an  offensive  sprit  on  the  battlefield, 
they  must  be  able  to  out-think  and  out-maneuver  the  enemy. 

The  successful  implementation  of  AirLand  Battle  doctrine  requires  highly  trained  soldiers.  Given  the 
lethality  of  modem  weapon  systems,  soldiers  must  know  how  to  fight  and  their  leaders  must  know  how  to 
command  before  the  battle  ever  begins.  Tim  use  of  the  battlefield  as  a  training  ground  is  no  longer  feasible  given 
the  relatively  low  probability  that  untrained  soldiers  can  survive  the  short  but  highly  intensive  battles  that 
characterize  modem  warfare. 

While  the  need  for  highly  trained  soldiers  has  increased,  the  difficulties  involved  in  meeting  this  need  have 
increased  as  well  Resources  such  as  fuel,  ammunition,  and  equipment  have  become  so  costly  that  field  exercise 
training  has  become  prohibitively  expensive.  At  the  same  time,  training  areas  have  become  sufficiently  scarce 
that  it  is  often  difficult  to  find  terrain  on  which  to  train  soldiers  to  make  maximum  use  of  the  speed,  firepower, 
and  operating  range  of  modem  weapon  systems. 

As  a  result  of  problems  such  as  these,  the  Army  has  explored  the  use  of  tactical  engagement  simulations; 
SCOPES  (Squad  Combat  Operation  Exercises  Simulation)  used  inexpensive  hardware  to  enable  two  opposing 
infantry  forces  to  actively  engage  one  another  in  a  free-play  environment  SCOPES  was  later  expanded  to 
indude  armor/anti-armor  with  the  development  of  REALTRAIN  (Realistic  Training),  and  these  systems 
eventually  evolved  into  MILES  (Multiple  Integrated  Laser  Engagement  System)  in  which  laser  systems  were 
used  to  assess  battlefield  casualties  in  real  time. 

While  the  use  of  tactical  engagement  simulations  has  enabled  the  Army  to  overcome  many  of  the 
problems  involved  in  preparing  soldiers  for  combat,  many  of  these  problems  remain  unsolved.  Land  is  still 
scarce,  and  fuel  continues  to  be  consumed  at  a  rapid  rate  during  tactical  engagement  simulation  field  exercises. 
In  addition,  extensive  use  of  military  equipment  for  training  shortens  the  combat  life  of  the  equipment  and 
escalates  their  maintenance  requirements. 

One  solution  to  these  problems  is  to  use  battle  simulations  to  supplement  some  of  the  training  that  would 
otherwise  be  conducted  in  the  field.  Battle  simulations  such  as  Dunn  Kempf,  ARTBASS  (Army  Training  Battle 
Simulation  System),  and  BABAS  (Battalion  Automated  Battle  Simulation)  already  have  proved  to  be  highly 
useful  in  training  soldiers  at  all  echelons  from  platoons  to  corps.  With  recent  advances  in  technology,  moreover, 
the  costs  involved  in  developing  battle  simulations  have  decreased  dramatically  while  their  capabilities  have 
actually  increased.  Given  these  cost  reductions  and  increased  capabilities,  it  is  likely  that  the  efforts  to  develop 
new  battle  simulations  will  continue  into  the  future. 


Because  of  the  complexity  of  the  technology  involved  in  designing  battle  simulations,  particularly  in 
designing  computer  based  and/or  computer  assisted  simulations,  the  users  of  these  products  must  rely  on  “hi 
tech”  specialists  for  their  development.  This  reliance  creates  a  potential  problem  which  can  have  unfortunate 
consequences  for  training.  Unless  the  user  is  sufficiently  involved  in  the  design  of  the  battle  simulation,  the 
resulting  product  may  not  perform  in  a  way  that  is  conducive  to  good  training.  Due  to  the  costs  and  efforts 
involved  in  the  development  of  the  product,  the  simulation  would  probably  have  to  be  used  regardless  of  its 
merits.  All  too  often  it  is  the  design  of  the  simulation  that  determines  how  training  is  conducted  rather  than  the 
other  way  around. 

The  solution  to  this  dilemma  is  for  the  user  to  carefully  specify  in  advance  the  functional  requirements  for 
the  battle  simulation.  That  is,  the  user  must  describe  in  detail  how  the  battlefield  situation  is  to  be  represented 
by  the  simulation  and  what  processes  must  be  included  to  enable  soldiers  to  perform  the  actions  they  would 
normally  perform  during  combat.  If  the  battle  simulation  were  to  be  an  exact  duplication  of  the  battlefield 
situation,  perhaps  this  would  not  be  difficult.  However,  duplicating  a  battlefield  situation  would  be  both 
prohibitively  expensive  and  highly  undesirable.  Many  of  the  characteristics  involved  in  the  actual  battlefield 
may  have  no  relationship  to  critical  training  objectives,  and  the  costs  involved  in  replicating  them  would  be 
wasted.  Moreover,  total  fidelity  may  actually  interfere  with  the  learning  process  and  should  probably  be 
avoided. 

Since  the  military  user  should  know  best  bow  the  simulation  should  be  used  during  training,  it  is  this 
person  who  should  describe  the  functional  requirements.  Unfortunately,  this  task  can  be  difficult  to  perform. 
The  user,  particularly  one  who  is  unfamiliar  with  specifying  requirements  for  automated  systems,  may  have 
difficulty  identifying  the  types  of  functions  that  must  be  represented  in  a  battle  simulation  and  in  specifying  the 
exact  requirements  for  each  function.  As  a  result,  the  user  will  often  leave  it  to  the  discretion  of  the  developer  to 
determine  the  specific  representations  and  processes  that  will  be  incorporated  into  the  simulation.  Consequently, 
the  developer,  rather  than  the  user,  all  too  often  will  determine  how  the  simulation  is  to  be  used  in  training.  The 
unfortunate  result  of  this  sequence  is  that  the  user  may  learn  once  the  system  is  completed  that  it  does  not 
function  in  the  way  that  had  been  anticipated.  By  the  time  this  realization  occurs,  it  is  usually  too  late  for 
modifications  to  be  made  without  incurring  additional  costs  and  delays. 
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PURPOSE 


'  The  purpose  of  this  paper  is  to  present  a  model  that  can  be  of  help  to  military  users  who  have  to  prepare 
functional  requirements  for  battle  simulations.  The  particular  functional  requirements  are  for  a  battle  simulation 
that  will  be  used  to  conduct  research  on  training  command,  control,  and  communications  (C3)  skills  among  the 
four  leaders  of  a  tank  platoon  (Le^  the  platoon  leader,  the  platoon  sergeant,  and  the  two  tank  commanders) 
during  tLe  performance  of  combined  arms  operations.  This  battle  simulation,  SIMCAT  (SIMuiation  in 
Combined  Arms  Training),  is  being  developed  for  the  U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences  (ART)  by  the  Human  Resources  Research  Organization  (HumRRO)  under  contract  MDA903- 
83-C-0504  with  Perce ptroaics  as  a  subcontractor.  The  functional  requirements  were  prepared  for  ARI  by 
HumRRO  and  w ere  provided  to  Perceptronics  for  the  hardware/software  development  of  SIMCAT. 

While  these  functional  requirements  are  specific  to  the  development  of  SIMCAT  and  the  purposes  for 
which  SIMCAT  was  intended,  they  are  being  presented  in  this  paper  to  serve  as  a  model  for  others  who  must 
prepare  functional  requirements  for  battle  simulations.  The  functions  for  which  requirements  are  provided  (e.g., 
terrain,  movement,  engagement,  communications)  must  be  considered  in  the  development  of  any  battle 
simulation.  While  the  requirements  will  obviously  vary  Grom  one  simulation  to  another,  it  is  hoped  that  their 
publication  will  assist  others  who  will  undertake  similar  tasks.  v 


BACKGROUND 

The  first  step  in  the  development  of  any  battle  simulation,  including  SIMCAT,  is  to  define  “what  the 
system  should  do,"  or,  in  the  context  of  this  document,  to  determine  its  functional  requirements.  The  functional 
requirements  that  have  been  prepared  for  SIMCAT  are  defined  and  recorded  in  this  document  which  has  been 
organized  into  the  following  sections: 

APPROACH  TO  THE  DEVELOPMENT  OF  THE  FUNCTIONAL  REQUIREMENTS  for  SIMCAT 
—  This  section  contains  a  description  of  the  procedure  that  was  used  to  identify  the  functional 
requirements  for  SIMCAT  and  addresses  the  issues  that  surfaced  during  the  development  and  execution  of 
this  procedure.  Also  contained  in  this  section  are  the  reasons  why  the  initial  configuration  of  SIMCAT  may 
not  satisfy  all  of  the  functional  requirements  that  are  described  in  this  document  Understanding  of  these 
issues  and  their  subsequent  resolutions  is  important  in  order  to  properly  interpret  the  contents  of  this 
document 

ANALYSIS  OF  THE  FUNCTIONAL  REQUIREMENTS  FOR  SIMCAT  —  Once  the  functional 
requirements  for  SIMCAT  are  documented,  several  analyses  must  be  performed  to  determine  technological 
alternatives  to  satisfying  the  requirements,  system  costs,  appropriate  allocation  of  development  resources, 
and,  based  on  the  aforementioned,  alternative  system  requirements.  Each  of  these  required  analyses  is 
described  in  this  section. 

IDENTIFICATION  OF  FUNCTIONAL  REQUIREMENTS  —  The  ten  categories  of  functional 
requirements  for  SIMCAT  are  identified  in  this  section,  and  a  general  definition  of  each  category  is 
provided. 

DESCRIPTION  OF  THE  FUNCTIONAL  REQUIREMENTS  FOR  SIMCAT  —  This  section  contains 
the  functional  requirements  for  SIMCAT  for  nine  of  the  ten  categories  that  were  identified.  The  description 
of  each  category  has  been  written  as  a  stand-alone  document 


APPROACH  TO  THE  DEVELOPMENT  OF  THE 
FUNCTIONAL  REQUIREMENTS  FOR  SIMCAT 


Before  attempting  to  identify  the  functional  requirements  for  SIMCAT,  it  was  necessary  to  clarify  the 
meaning  of  the  term  “functional  requirements”.  In  this  document,  functional  requirements  will  be  defined  as  the 
processes  and  representations  that  the  SIMCAT  system  must  satisfy  to  achieve  its  intended  training  goals. 
Processes  are  those  functions  that  are  necessary  to  permit  tank  platoon  leaders,  platoon  sergeants,  and  tank 
commanders  to  perform  tasks  normally  associated  with  the  operation  of  a  tank  in  a  field  environment 
Representations  are  the  visual  and  auditory  stimuli  to  which  tank  platoon  leadership  personnel  would  normally 
be  exposed  when  executing  tactical  activities  in  a  field  environment 

SIMCAT  functional  requirements  could  be  derived  from  a  variety  of  sources  such  as  training  objectives, 
representative  tactical  scenarios,  task  inventories,  Army  Training  and  Evaluation  Programs  (ARTEPs), 
situational  training  exercises  (STXs),  or  battle  drills.  Synthesizing  the  functional  requirements  horn  any  single 
source  would  have  been  risky  because  of  the  difficulty  involved  in  determining  the  degree  to  which  a  set  of 
scenarios  is  representative  of  combined  arms  operations  or  a  task  inventory  is  complete.  For  this  reason,  it  was 
decided  to  draw  upon  all  of  these  sources  collectively. 

Once  it  had  been  determined  from  which  data  sources  the  functional  requirements  were  to  be  derived,  a 
starting  point  had  to  be  identified.  It  was  agreed  three  representative  scenarios  would  serve  as  this  starting  point 
Two  of  these  scenarios  were  then  developed  (hasty  attack  and  movement-to-contact)  and  an  outline  of  the 
defend  battle  position  scenario  was  formulated.  Each  scenario  reflected  SIMCAPs  training  goals,  armor 
platoon  task  inventories,  and  doctrine,  as  well  as  ARTEPs  and  training  techniques  (e.g.,  battle  drills,  STXs). 

With  the  initial  focus  on  the  scenarios,  the  functional  requirements  for  SIMCAT  began  to  emerge. 
However,  the  scenarios  could  not  be  viewed  in  isolation.  Although  they  were  based  upon  the  aforementioned 
data  sources  (e.g.,  task  inventories,  ARTEPs,  etc.),  these  sources  had  to  be  referenced  repeatedly  in  conjunction 
with  the  scenarios  before  functional  requirements  could  be  determined.  This  was  because  the  process  and 
representation  requirements  could  not  be  derived  from  the  scenarios  alone.  An  example  of  this  occurred  when  a 
scenario  required  an  Ml  tank  to  engage  an  opposition  force  (OPFOR)  tank.  Although  various  conditional 
factors  were  specified  (such  as  the  locations  of  the  vehicles  involved),  it  could  not  be  determined  from  the 
scenario  alone  what  specific  SIMCAT  functional  requirements  were  necessary.  As  a  result,  attention  had  to  be 
focused  on  the  other  data  sources  (in  this  case,  task  inventories  and  FMs).  The  specific  processes  (e.g., 
movement,  firing  main  gun)  and  representations  (e.g.,  weapon  signatures)  that  SIMCAT  had  to  satisfy  to 
accommodate  the  engagement  described  in  the  scenario  was  determined  from  these  data  sources.  The  result  was 
an  iterative,  cyclic,  and  deductive  procedure  or  approach  to  identifying  SIMCATs  functional  requirements. 

Following  initial  review  of  the  scenarios  and  other  relevant  data  sources,  ten  categories  of  functional 
requirements  were  identified.  Once  this  was  done,  it  was  then  necessary  to  prepare  each  functional  requirement 
in  detail.  During  this  process,  several  questions  surfaced  repeatedly  which  dictated  the  need  to  establish  some 
guidelines  in  considering  functional  requirements.  Specifically,  the  following  guidelines  were  adopted: 

•  The  80%  Solution  —  It  was  realized  at  the  onset  that  SIMCAT  could  not  accommodate  all  possible 
conditions  experienced  by  armor  platoons  on  the  battlefield.  Therefore,  it  was  decided  that  the  focus 
would  be  on  conditions  that  were  the  rule,  rather  than  exceptions  to  the  rule.  Thus  it  was  arbitrarily 
decided  that  a  condition  must  have  a  high  probability  of  occurring  on  the  battlefield  in  order  to  be 
accommodated  by  the  functional  requirements. 

•  Cost  Constraints  —  Robust  research  practice  would  dictate  that  the  functional  requirements  for 
SIMCAT  be  determined  primarily  on  the  basis  of  its  training  goals.  Reality,  however,  dictated  limits  to 
the  initial  hardware  configuration  costs  for  SIMCAT.  Given  that  the  costs  associated  with  a  functional 


requirement  could  be  estimated  at  the  time  it  was  identified,  these  cost  constraints  could  not  be  ignored. 
Therefore,  costs  were  considered  and  any  functional  requirement  which  would  have  necessitated  a 
prohibitive  expenditure  was  disregarded. 

•  Training  Focus  —  Since  SIMCAT  is  to  serve  initially  as  a  research  vehicle  on  training  tank  platoon 
leadership,  it  constantly  had  to  be  kept  in  mind  that  SIMCAT  was  not  to  serve  as  either  a  tank  gunnery 
or  crew  trainer.  Gunnery  and  crew-related  tasks  and  their  associated  functional  requirements,  therefore, 
were  neither  a  primary  concern  nor,  in  many  cases,  even  desirable.1  For  example,  a  TC  has  the  option 
of  sighting  and  firing  the  main  gun.  No  functional  requirements  were  identified  for  this  activity  for  two 
reasons.  First,  sighting  and  firing  the  main  gun  was  related  to  tank  gunnery.  Second,  since  the  gunner 
normally  fires  the  main  gun,  the  80%  solution  was  applied. 

•  System  Design  —  The  functional  requirements  were  to  be  restricted  originally  to  the  processes  and 
representations  that  SIMCAT  must  satisfy  to  achieve  its  training  goals.  The  hardware  and/or  software 
requirements  were  to  be  neither  stated  nor  implied.  However,  some  functional  requirements  dictated 
obvious  hardware/software  requirements.  Where  this  occurred,  the  these  requirements  were  specified. 
As  an  example,  one  situation  arose  in  which  the  only  way  that  a  particular  set  of  functional 
requirements  could  be  satisfied  was  through  voice  synthesis  and  speech  recognition.  Taking  into 
consideration  the  fidelity  requirements,  the  burden  placed  on  the  SIMCAT  controller/trainer  position, 
and  the  cost,  voice  technology  was  deemed  the  only  feasible  manner  in  which  a  particular  set  of 
functional  requirements  could  be  satisfied.  Rather  than  expending  the  effort  that  would  have  been 
required  to  identify  functions  from  which  one  would  determine  a  need  for  voice  synthesis/recognition, 
this  requirement  was  stated  directly. 

•  Fidelity  —  If  SIMCAT  could  replicate  a  real  battlefield  environment  (Le.,  achieve  100  percent  fidelity), 
one  could  be  assured  it  would  satisfy  all  current  as  well  as  future  training  requirements.  However,  even 
if  such  a  system  were  technologically  feasible,  the  cost  would  be  prohibitive.  Therefore,  fidelity 
requirements  were  considered  on  a  case-by-case  basis  as  the  functional  requirements  were  developed. 
Although  the  level  of  fidelity  required  in  a  simulation  has  been  the  subject  of  much  debate  in  research, 
satisfactory  criteria  or  methodologies  for  determining  simulation  fidelity  requirements  have  yet  to  be 
developed.  However,  since  the  issue  of  fidelity  could  not  be  avoided  in  defining  the  functional 
requirements  for  SIMCAT,  subjective,  but  sound,  fidelity  criteria  (based  primarily  on  cost  constraints, 
technological  feasibility,  and  stated  or  implied  training  goals)  were  applied. 


ANALYSIS  OF  THE  FUNCTIONAL  REQUIREMENTS  FOR  SIMCAT 

The  functional  requirements  contained  in  this  document  were  analyzed  individually  and  collectively  for 
several  purposes.  Specifically,  these  analyses  determined: 

•  Availability  of  Existing  and  Alternative  Technologies  —  Here  it  was  determined  which  hardware 
technologies,  software  technologies,  or  combinations  thereof  currently  exist  that  could  satisfy  each 
functional  requirement.  Alternative  technologies  (each  resulting  in  varying  degrees  of  fidelity)  that  could 
be  used  for  satisfying  each  set  of  functional  requirements  were  identified  and  documented. 


'Thu  is  not  to  ity  gunnery-  and  crew-related  activities  were  totally  ignored.  However,  they  were  addrested  only  to  the  degree  that  they  contributed 
to  or  detracted  from  the  fidelity  of  a  TCs  C5  activities. 
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•  Cost  —  The  costs  associated  with  each  technology  alternative  identified  was  determined  and 
documented  These  costs  included  not  only  hardware,  but  any  associated  software  packages  and/or  the 
development  of  software. 

•  Allocation  of  Resources  —  Given  technological  alternatives  and  the  costs  associated  with  each,  a 
resource  allocation  analysis  was  planned  This  analysis  would  involve  treating  each  functional 
requirement  (individually  or  in  sets)  as  the  key  variable.  For  each  functional  requirement,  several  levels 
of  fidelity  would  be  established  (e.g.,  high,  medium,  low,  and  very  low).  For  each  fidelity  level,  a  cost 
and  benefit/udlity/desirability  value  will  be  assigned  The  cost  value  would  be  based  upon  the 
technological  alternatives  and  costs  resulting  from  the  previous  analyses.  The  benefit/udlity/desirability 
value  assigned  to  each  fidelity  level  would  reflect  a  subjective  appraisal  of  the  training  value  of  that 
fidelity  level  in  terms  of  such  factors  as  transferability  to  a  field  environment  and  relevance  to  achieving 
training  goals.  Once  each  of  these  values  for  individual  sets  of  functional  requirements  had  been 
specified  resource  allocation  analyses  would  be  performed  These  analyses  could  be  keyed  to  any 
variable  contained  in  the  database,  e.g.,  benefit/  utility  /desirability,  fidelity,  or  costs. 

•  Alternative  Configurations  —  The  resource  allocation  analyses  would  have  resulted  in  identification  of 
alternative  SIMCAT  configurations.  These  alternatives  would  be  described  in  terms  of  the  variables 
considered  in  the  resource  allocation  analyses,  e.g.,  level  of  fidelity,  costs,  or  benefits. 

These  analyses  will  be  performed  in  the  near  future.  The  product  of  these  analyses  will  be  the 
identification  of  two  alternative  system  configurations  and  associated  costs,  i.e.,  a  high  cost  and  a  low  cost 
configuration.  It  is  anticipated  that  the  high  cost  alternative  will  be  capable  of  satisfying  ail  the  functional 
requirements  specified  in  this  document  Conversely,  it  is  realized  that  some  of  the  functional  requirements 
defined  may  not  be  satisfied  by  the  low  cost  alternative. 


IDENTIFICATION  OF  FUNCTIONAL  REQUIREMENTS 

SIMCAT  must  satisfy  a  multitude  of  vastly  different  functional  requirements.  To  define  these,  some  form 
of  classification  is  required  so  that  they  can  be  organized  and  comprehensible.  Such  a  classification  evolved 
during  the  development  of  the  functional  requirements.  Specifically,  ten  categories  of  functional  requirements 
were  classified  as  follows: 

•  Initialization  —  These  functional  requirements  involve  the  system  processes  necessary  to  begin  a 
SIMCAT  simulation,  e.g.,  identification  of  scenario  conditions  (such  as  TO&Es  and  missions  for  each 
of  the  opposing  forces)  speech  enrollments  (necessary  if  voice  recognition  is  involved),  and  selection  of 
terrain.  Since  initialization  functional  requirements  are  dependent  upon  the  manner  in  which  the 
remaining  nine  categories  of  functional  requirements  are  going  to  be  satisfied,  this  category  of  functional 
requirements  has  yet  to  be  developed.  Once  it  is  resolved  which  functional  requirements  specified  in  this 
document  are  going  to  be  pursued  and  the  manner  in  which  each  is  going  to  be  satisfied,  this  category 
of  functional  requirements  will  be  developed. 

•  Terrain  —  These  functional  requirements  involve  providing  each  SIMCAT  position  (i.e..  controller/ 
trainer,  trainee,  and  OPFOR)  with  knowledge  about  the  terrain  in  which  he  is  operating,  or,  in  the  case 
of  the  controller/trainer,  the  terrain  within  which  both  the  OPFOR  and  friendly  forces  are  operating. 
These  functional  requirements  are  defined  in  terms  of  terrain  characteristics,  trafficability,  and  the 
perception  requirements  for  each  SIMCAT  position. 


•  Movement  —  The  process  and  representation  requirements  for  movement  are  defined  as  they  relate  to 
the  object  that  is  moving,  the  rate  of  movement,  the  control  of  movement,  and  the  perception  of 
movement 

•  Detection/Identification  —  This  category  of  functional  requirements  concerns  the  relevant  objects, 
events,  and  conditions  of  the  simulation  environment  that  may  be  detected  and  possibly  identified  by 
each  participant  in  a  SIMCAT  simulation. 

•  Engagement  —  The  purpose  of  the  functional  requirements  for  engagement  is  to  resolve  ail  encounters 
between  the  military  weapon  systems  being  simulated  in  a  scenario.  An  encounter,  in  this  context,  is 
defined  as  the  firing  of  one  or  more  OPFOR  or  friendly  forces  weapon  systems  and  the  effect,  if  any,  on 
the  engaged  targets). 

•  Indirect  Fire  —  Dedicated  indirect  fire  support  will  be  provided  to  each  of  the  opposing  forces  in  all 
SIMCAT  scenarios.  To  satisfy  this  requirement,  SIMCAT  must  maintain  a  record  of  ail  indirect  fire 
allocations,  provide  a  means  for  requesting  indirect  fire,  impact  indirect  fires,  and  represent  the  effects  to 
appropriate  SIMCAT  positions.  The  representation  and  process  requirements  necessary  to  satisfy  each 
of  these  are  discussed  in  detail. 

•  Communication  —  The  communication  functional  requirements  are  specified  in  terms  of  four 
communication  networks  (nets):  platoon,  company  team,  tank  intercom,  and  controller.  The  purpose  of 
each  net  and  the  SIMCAT  positions  involved  in  each  net  are  defined. 

•  Resources  Audit  —  These  functional  requirements  dictate  that  SIMCAT  maintain  an  audit  of  all 
munitions  and  fuel  expended  by  each  weapon  system  and  vehicle  simulated  in  a  scenario.  Given  a 
specified  allocation  of  fuel  or  munitions,  SIMCAT  must  audit  the  expenditures  of  these  resources  as 
they  occur  and  prevent  further  expenditures  once  a  resource  has  been  exhausted. 

•  Time  —  These  functional  requirements  dictate  that  SIMCAT  be  sensitive  to  and  represent  two  different 
types  of  time:  simulation  time  and  real  time.  Each  of  these  types  of  time  will  be  discussed  and 
information  on  the  functional  requirements  regarding  simulation  time  will  follow. 

•  Post-Simulation  —  These  functional  requirements  specify  the  SIMCAT  processes  necessary  to  support 
controller/trainer  responsibilities  associated  with  providing  feedback  to  trainees.  Post-simulation 
functional  requirements  are  divided  into  three  categories:  visual  playback,  audio  or  communication 
playback,  and  hard  copy  outputs. 


DESCRIPTIONS  OF  THE  FUNCTIONAL  REQUIREMENTS  FOR  SIMCAT 

The  following  pages  contain  separate  sections  for  nine  of  the  ten  functional  requirements  identified 
previously.1  Each  section  varies  in  format  because  the  nature  of  each  functional  requirement  varies.  For 
example,  some  functional  requirements  emphasize  process  requirements  while  others  emphasize  representation 
requirements.  In  cases  where  the  rationale  for  a  functional  requirement  was  obvious,  the  rationale  was  not 
documented;  where  a  rationale  was  less  obvious,  an  effort  was  made  to  document  it.  Where  appropriate,  tables 
and  figures  are  used  to  further  define  functional  requirements. 
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TERRAIN 


The  functional  requirements  for  terrain  are  to  provide  the  trainees  and  the  OPFOR  knowledge  of  the 
terrain  in  which  they  are  operating,  and  to  provide  the  controller/trainer  knowledge  of  the  terrain  in  which 
both  the  OPFOR  and  friendly  forces  (trainees)  are  operating.  Terrain  functional  requirements  are  diseased 
below  in  terms  of  characteristics,  traificability,  and  perception. 

Characteristics 

Terrain  characteristics  are  the  natural  and/or  man-made  objects  to  be  found  in  the  tactical  scenarios 
inherent  in  SIMCAT.  In  the  real  world,  an  indefinite  number  or  type  of  terrain  characteristics  are  possible. 
SIMCAT  terrain  characteristics,  however,  are  restricted  to  representations  of  the  following: 

•  Man-Made  Objects: 

—  Intact  bridge  (i.e.,  overpass) 

—  Blown  primary  road  bridge  over  a  stream 
—  Paved  secondary  road 
—  Major  road  (two-lane,  concrete) 

—  Underpass  (secondary  road  overpassing  a  major  road) 

—  Exposed  mines  across  a  major  roadway 
—  Hidden  mine  fields 

•  Vegetation  and  water 

—  Woods  (traversable  in  a  tank) 

—  Open,  traversable  grasslands 
—  Stream  with  depth  of  12  feet  or  more 
—  Small  poods 

•  Relief: 

—  Hills  with  elevations  ranging  from  100  feet  to  300  feet 
—  Tank  traversable  ridge 
—  Nontraversable  (for  tanks)  stream  bank. 

TrafficabOity 

Trafficability  is  the  effect  of  terrain  on  movement  rates  and  traversability  (e.g.,  tanks  can  traverse  open, 
relatively  flat  grasslands,  but  cannot  traverse  a  30  foot  high,  90°  bank).  Trafficability  functional  requirements 
do  not  dictate  any  representation  requirements,  but  dictate  several  modeling  requirements  (i.e.,  friendly  tanks 
should  not  be  permitted  to  move  at  their  maximum  rate  in  wooded  terrain).  These  modeling  requirements  are 
specified  later  in  the  section  on  movement  functional  requirements  for  SIMCAT. 


Perception 

Each  SIMCAT  position  requires  a  somewhat  different  perception  of  terrain.  This  difference  in  perception 
only  relates  to  the  area  or  size  of  the  piece  (and,  consequently  the  scale)  of  the  terrain  which  is  represented  to 
each  position.  Specifically,  these  perception  requirements  are  as  follows: 

•  Trainees  —  Each  trainee  should  have  represented  to  him  only  the  terrain  which  is  within  his  line  of 
sight  given  his  location  relative  to  terrain  characteristics  (e.g.,  vegetation  and  relief)  and  obscurants  (e.g.. 


smoke).  Each  trainee  should  be  provided  with  a  360°  perspective  of  the  terrain  given  the 
aforementioned  constraints.  Because  it  is  impossible  for  two  tanks  to  occupy  the  same  space 
simultaneously,  this  requirement  dictates  that  each  trainee  be  provided  with  a  somewhat  different  terrain 
representation.  Also,  since  each  trainee  will  have  the  ability  to  move  in  any  direction  at  any  time,  each 
of  these  terrain  representations  will  change  and  it  will  be  necessary  for  SIMCAT  to  represent  each  tank 
position  cn  the  terrain. 

•  OPFOR  —  There  will  be  a  single  individual  controlling  all  OPFOR  vehicles  and  weapon  systems.1 
These  vehicles  will  seldom,  if  ever,  be  in  dose  proximity  to  one  another  (correspondingly,  in  a  real 
situation,  seldom  will  each  vehicle  have  all  other  vehides  in  visual  sight).  Instead,  they  usually  will  be 
dispersed.  Because  the  OPFOR  player  must  be  aware  of  the  location  of  all  of  these  vehicles  at  all  times, 
and  because  they  are  likely  to  be  dispersed,  a  large  area  of  terrain  (relative  to  what  is  to  be  represented 
to  each  trainee)  must  be  represented  to  the  OPFOR  player.  As  in  the  case  of  the  trainee  position,  only 
the  terrain  which  is  within  the  line  of  sight  of  the  vehides  and  weapon  systems  he  is  controlling  should 
be  represented  to  the  OPFOR  player.  Once  line  of  sight  (360°  perspective)  for  each  OPFOR  vehide 
has  been  determined  by  SIMCAT,  the  terrain  representation  requirements  for  each  vehide  should  then 
be  presented  to  the  OPFOR  position. 

•  Controller/T rainer  —  The  terrain  represented  to  the  controller/trainer  will  encompass  an  area  even 
larger  than  that  presented  to  the  OPFOR  position.  This  is  necessary  because  the  controller/trainer  must 
be  provided  with  a  “God’s-eye”  view  of  the  entire  area  occupied  by  both  friendly  forces  and  OPFOR. 
This  functional  requirement  should  not  be  interpreted  to  mean  that  the  entire  offensive  zone  of 
operation  for  the  friendly  force  must  be  represented  to  the  controller/trainer  at  any  point  This  will 
seldom,  if  ever,  be  necessary.  Instead,  three  possible  controller/trainer  terrain  representations  are 
envisioned: 

—  Initial  Defensive  Position.  Once  a  defense  has  been  established  (by  either  an  OPFOR  or  friendly 
force),  the  controller/trainer  must  be  provided  with  a  “God’s-eye”  view  of  the  defensive  zone.  This 
zone  should  indude  all  of  the  terrain  within  line  of  sight  of  all  defensive  positions  collectively.  At 
this  point  it  will  not  be  necessary  to  represent  the  terrain  within  the  line  of  sight  of  offensive  forces. 

—  Movement  Zone.  Once  an  offense  force  has  crossed  its  LD  (line  of  departure),  the  terrain 
represented  to  the  controller/trainer  need  only  show  a  “God’s-eye”  view  of  the  offensive  movement 
area.  This  terrain  representation  should  be  a  composite  of  the  terrain  within  the  line  of  sight  of  all 
offensive  vehides  collectively.  At  this  point,  it  will  not  be  necessary  to  represent  the  terrain  within 
the  line  of  sight  of  defensive  vehicles. 

—  Offense/  Defense  Merge.  At  the  point  where  one  or  more  offensive  vehides  are  within  line  of  sight 
of  one  or  more  defensive  vehides,  SIMCAT  should  automatically  provide  the  controller/trainer 
with  a  composite  terrain  representation  of  all  terrain  occupied  by  and  within  the  line  of  sight  of  all 
offensive  and  defensive  vehides.  This  terrain  representation  need  not  indude  terrain  to  the  rear  of 
the  defense  nor  to  the  rear  of  the  last  vehide  of  the  offense. 

NOTE:  The  three  controller/trainer  terrain  representations  should  involve  at  least  three  different 
scale  terrain  representations.  This  approach  permits  the  controller/trainer  to  switch  views  between 
offense  and  defense  until  detection  occurs.  At  this  point,  the  controller/trainer  should  have  no 
control  or  choice  of  what  is  represented.  Upon  detection,  the  terrain  representation  should  indude 
all  terrain  within  the  line  of  sight  of  all  vehides  (offense  and  defense)  involved  in  the  simulation. 
This  perspective  is  necessary  if  the  controller/trainer  is  to  monitor  all  activities. 


■There  will  be  maximum  of  tea  OPFOR  vettda  and/or  weapon  system  doe  to  cor 


•-  *.  %  *. 


\  V 


MOVEMENT 

Determining  what  moves,  the  rate  at  which  something  moves,  the  control  of  movement,  and  the 
perception  of  movement  are  all  critical  to  SIMCAT  achieving  the  training  objectives  of  SIMCAT.  The 
movement  functional  requirements  vary,  depending  on  the  SIMCAT  position  being  addressed: 

Trainee  —  The  platoon  leader,  platoon  sergeant,  and  two  tank  commanders  will  each  control  the 
movement  of  his  own  tank.  The  movement  functional  requirements  for  this  position  are  covered  in  the 
following  subsections: 

•  Trainee  Tank  Movement 

•  Trainee  Tank  Engine  Control 

•  Trainee  Tuiret/Main  Gun  Movement 

OPFOR  —  One  person  will  control  the  movement  of  all  OPFOR  elements  (i.e.,  tanks  or  other  vehicles 
and  their  associated  weapon  systems).  The  movement  functional  requirements  for  this  position  are  covered 
in  the  following  subsections: 

•  OPFOR  Vehicle  T72  Tank  and  BMP  Movement 

•  OPFOR  T72  Tank  Turret  and  BMP  73mm  Gun/Sagger  Movement 

Controller /Trainer  —  A  single  individual  wiO  be  responsible  for  controlling  the  entire  SIMCAT 
simulation.  The  control  is  limited  to  creating  the  initial  conditions,  monitoring  the  actions  of  both 
OPFOR  and  friendly  forces  for  the  duration  of  the  simulation,  and  providing  feedback  to  all  participants 
both  during  and  after  the  simulation.  With  respect  to  movement  functional  requirements  for  SIMCAT,  it 
is  the  monitoring  responsibilities  of  the  controller  that  are  of  most  concern.  The  movement  functional 
requirements  for  this  position  are  covered  in  the  following  subsection: 

•  Controller/Trainer  Movement  Requirements 

Each  of  these  movement  functional  requirements,  with  the  exception  of  trainee  tank  engine  control,  will 
be  discussed  individually  in  terms  of  direction,  rate,  control,  and  perception.  For  purposes  of  this  discussion, 
these  terms  are  defined  as  follows: 

Direction  —  The  line  or  course  (expressed  in  terms  of  degrees)  on  which  a  simulated  vehicle  and  its  turret 
(in  the  case  of  a  trainee  only)  is  permitted  to  move. 

Rate  —  The  speed  at  which  a  simulated  vehicle  or  turret  is  moving. 

Control  —  The  manner  in  which  both  the  direction  and  rate  of  movement  the  simulated  vehicles  or 
turrets  are  controlled.  Control  requirements  will  vary  depending  on  the  SIMCAT  position  being 
addressed. 

Perception  —  The  visual  image  of  movement  which  must  be  portrayed  to  each  SIMCAT  position.  The 
visual  image  movement  requirements  will  vary  depending  on  the  particular  position. 


Trainee  Tank  Movement 

A  trainee  will  be  responsible  for  controlling  the  movement  of  his  tank  in  all  situations,  including  combat. 
In  this  context,  movement  includes  both  the  direction  in  which  a  tank  moves  and  its  rate  of  speed.  It  is 
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imperative  that  SIMCAT  permit  the  trainee  to  control  the  movement  of  his  tank.  Specifically,  this  requires 
SIMCAT  to  satisfy  the  following  functional  requirements: 


Direction 

Each  trainee  must  be  capable  of  moving  his  tank  in  any  direction  (i.e„  360°)  at  any  point  on  terrain 
representation,  and  at  any  time  during  simulation. 

Regarding  the  area  of  operation,  SIMCAT  must  restrict  movement  to  the  platoon  tone  of  operation. 
SIMCAT  should  automatically  prevent  a  trainee  from  moving  outside  of  this  zone  by  automatically  generating 
a  message  from  the  company  team  leader  advising  the  trainee  of  his  error. 


Rate 


Maximum  rate  of  speed  for  Ml  Abrams  tank*  will  differ  depending  on  the  following  terrain 
characteristics  or  driving  conditions: 

•  Primary  and  Secondary  Roads:  40  MPH 

•  Open,  Traversable  Grasslands:  20  MPH 

•  Wooded  Areas:  10  MPH 

•  Any  Grade:  20  MPH 

•  Stream  Ford:  4  MPH 

•  Moving  in  Reverse:  10  MPH 

NOTE:  These  are  maximum  speeds  for  the  conditions  specified.  Trainees  have  the  option  of  moving  at 
slower  rates  (see  below) 


Control 

Each  trainee  must  have  control  of  both  the  direction  and  rate  at  which  his  tank  is  moving.  To  achieve  the 
fidelity  necessary  to  satisfy  training  requirements,  this  control  should  involve  tank  commander-to-driver  voice 
commands  as  follows: 

•  Controlling  Direction  —  Direction  of  tank  movement  must  be  controlled  verbally  by  each  trainee 

using  formal  driving  commands.  These  commands  will  be  restricted  to  the  following: 

—  “Driver  Move  Out”  (Tank  must  respond  by  moving  forward,  i.e.,  the  direction  in  which  the  tank  is 
pointed  at  the  time  the  command  is  given). 

—  “Driver  Stop” 

—  “Driver  Turn  Left” 

—  “Driver  Turn  Right” 

—  “Driver  Guide  Left” 

—  “Driver  Guide  Right” 

—  “Driver  Steady  On” 

—  “Driver  Rear”  (Tank  must  respond  by  moving  in  reverse,  Le^  the  opposite  direction  in  which  the 
tank  is  pointed  at  the  time  the  command  is  given). 

—  “Driver  Sagger,  Sagger”  (Tank  will  continue  in  the  direction  of  the  last  command,  but  must  begin 
to  zig-zag.  The  zig-zag  movement  pattern  must  continue  for  fifteen  seconds  or  until  another  driving 
command  is  issued,  whichever  occurs  first). 


NOTE:  Given  a  movement  command,  the  tank  must  continue  to  follow  that  command  until  another 
command  is  issued  or  until  a  nontraversable  terrain  feature  is  encountered.  In  other  words,  SIMCAT  will 
assume  a  nonintelligent  (i.eM  non-decision-  making )  driver.  Therefore,  a  tank  will  not  stop  automatically  at 
the  crest  of  a  hill;  it  will  stop  only  when  the  TC  issues  a  stop  command  to  the  driver. 

•  Controlling  Rate  —  Following  a  direction  command,  rate  of  movement  must  be  at  the  maximum  rate 
of  movement  given  terrain  characteristics  (see  previous  section  on  controlling  rate).  However,  the  TC 
must  be  able  to  decrease  and  subsequently  increase  his  tank  movement  rate  at  any  time.  Therefore,  to 
control  the  rate  of  movement,  the  following  TC-to-driver  voice  commands  and  subsequent  movement 
rates  are  required: 

—  “Driver  Slower”  —  The  rate  of  movement  is  immediately  decreased  by  50%.  This  command  can 
be  issued  until  the  tank  reaches  2  MPH,  at  which  time  the  system  will  ignore  any  additional 
“Driver  Slower”  commands.  For  example,  if  a  tank  is  moving  at  40  MPH  and  the  TC  issues  a 
“Driver  Slower”  command,  movement  rate  is  decreased  to  20  MPH.  If  at  this  point,  the  TC  issues 
another  “Driver  Slower”  command,  the  movement  rate  is  decreased  to  10  MPH.  Should  another 
“Driver  Slower”  command  be  issued,  the  movement  rate  immediately  decreases  to  5  MPH.  Should 
the  TC  issue  another  “Driver  Slower”  command,  SIMCAT  would  decrease  the  speed  to  2-1/2 
MPH.  Any  additional  “Driver  Slower”  commands  would  be  ignored  by  SIMCAT  because  the 
resulting  speed  would  be  less  than  the  2  MPH  minimum  speed  allowed. 

—  “Driver  Faster”  —  Tank  movement  rate  doubles  until  maximum  rate  of  movement  is  obtained. 
Because  the  rate  of  movement  will  always  be  the  maximum  rate  of  movement  given  terrain 
characteristics,  this  command  will  be  effective  only  when  it  follows  one  or  more  “Driver  Slower” 
commands.  If  a  tank  is  moving  at  the  maximum  rate  and  the  TC  commands  “Driver  Faster  ”  the 
SIMCAT  response  should  be  “I  can’t  go  any  faster!” 

NOTE:  If  at  any  point  a  tank  is  moving  at  less  than  maximum  rate  and  a  “Sagger,  Sagger”  message  is 
issued,  tank  movement  rate  should  automatically  resume  maximum  movement  rate  and  begin  a  zig-zag 
pattern. 


Perception 

Each  trainee  must  always  be  aware  of  the  following  regarding  his  tank: 

•  Tank  Orientation  —  The  front  of  a  trainee’s  vehicle  must  always  be  indicated  in  some  manner.  This  is 
necessary  because  the  trainee  must  be  aware  of  the  orientation  of  his  tank  before  he  can  determine  the 
appropriate  direction  command  to  be  given. 

•  Direction  of  Movement  —  Any  time  a  trainee’s  tank  is  moving,  the  trainee  must  be  made  aware  of  the 
direction  of  that  movement 

•  Rate  of  Movement  —  Each  trainee  must  be  capable  of  discerning  the  movement  rate  of  his  tank.  To 
accomplish  this,  the  movement  rate  of  the  tank  symbologies  should  be  to  scale  of  the  terrain 
representation.  Having  done  this,  the  trainee  hopefully  should  be  able  to  distinguish  among  varying 
rates  of  movement  of  his  tank. 
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Trainee  Tank  Engine  Control 

Trainees  win  be  controlling  simulation  of  Ml  Abrams  tank*.  Since  these  r*nk«  have  a  rapid  fuel 
consumption  nue,  a  trainee  may  choose  to  turn  the  engine  off  when  his  tank  is  stationary  (e.g.,  when  defending 
a  battle  position).  When  the  engine  is  off;  power  for  the  tank’s  systems  [e.g.,  thermal  imagery  sight  (TTS),  tank 
turret  movement]  is  provided  by  batteries.  Therefore,  SIMCAT  must  provide  each  trainee  the  capability  to 
control  the  running  of  his  tank’s  engine.  This  dictates  the  following  tank  engine  control  functional  requirements: 


Control 

Each  trainee  position  must  be  provided  the  ability  to  turn  the  tank  engine  to  “off  ”  and  “on.”  Although 
this  is  normally  accomplished  via  commands  from  the  TC  to  the  driver,  this  level  of  fidelity  is  not  required.  A 
simple  “Engine  On”  and  “Engine  Off”  button  would  suffice.  It  should  be  noted  that  when  an  engine  is  turned 
to  “off,”  the  tank  should  not  respond  to  movement  commands. 


Perception 

SIMCAT  must  provide  a  constant  cue  to  the  trainee  signifying  whether  or  not  the  engine  on  his  tank  is 
running.  However,  as  was  the  case  with  control,  fidelity  is  not  of  great  concern.  Therefore,  SIMCAT  need  not 
necessarily  provide  a  constant  “engine  running”  auditory  cue  (e.g.,  the  sound  of  an  engine  running  when  the 
engine  is  running)  nor  constant  “silence”  when  the  engine  is  not  running.  An  acceptable  alternative  might  be  to 
have  the  “Engine  On”  and  “Engine  Off”  buttons  light  up  when  one  or  the  other  is  in  effect 


Trainee  Turret/Main  Gun  Movement 

The  position  of  the  turret  (i.e.,  the  orientation  of  the  main  gun)  is  critical  to  combat  effectiveness  of  a 
tank.  Since  main  gun  orientation  is  the  responsibility  of  the  tank  commander,  it  is  imperative  that  SIMCAT 
attend  to  the  following  functions  associated  with  turret/ main  gun  movement: 


Direction 

At  any  point,  the  trainee  must  be  capable  of  positioning  the  turret/main  gun  in  any  direction  (i.e.,  360°). 
He  must  be  able  to  do  this  whether  the  tank  is  stationary  or  moving. 


Rate 

Turret/main  gun  movement  rate  is  not  of  great  concern.  However,  it  should  neither  require  a  great  deal  of 
time  nor  occur  at  such  a  rapid  rate  that  it  is  difficult  to  control. 


The  mechanism  or  procedure  for  positioning  the  turret/ main  gun  need  not  be  high  fidelity.  SIMCAT 
artifacts  (e.g.,  joystick,  function  keys)  are  acceptable. 


Perception 

Each  trainee  must  always  be  aware  of  the  position  of  the  turret  on  his  tank.  Again,  fidelity  is  not  of 
concent;  some  form  of  symbology  is  acceptable. 


OPFOR  Vehicle  Movement 

Movement  of  all  of  the  vehicles  and  weapon  systems  under  his  control  is  essential  to  the  OPFOR 
position.  SIMCAT,  therefore,  must  provide  the  OPFOR  position  the  capability  to  move  his  vehicles  both 
individually  and  together  as  a  group.  This  would  dictate  the  following  OPFOR  vehicle  movement  functional 
requirements: 


Direction 

At  any  point  on  terrain  representation,  and  at  any  time  during  simulation,  the  OPFOR  position  must  be 
capable  of  moving  any  of  the  vehicle  and/or  weapon  systems  he  controls  in  any  direction  (i.e.,  360°).  He  must 
be  permitted  to  move  cadi  of  his  vehicles  individually  as  well  as  in  unison.  The  latter  requirement  is  necessary 
in  situations  where  several  of  his  vehicles  are  in  contact  and  the  time  required  to  move  each  vehicle 
individually  would  be  prohibitive  (e.g.,  would  result  in  exposure  of  his  vehicles  to  enemy  fire  for  an  unrealistic 
period  of  time). 


Rate 

Rates  of  movement  would  be  identical  to  those  specified  for  friendly  force  tanks.  Under  all  conditions, 
OPFOR  vehicles  will  move  at  maximum  rates  given  the  constraints  imposed  by  terrain  features,  obscurants, 
and  illumination. 


Control 

Given  that  the  OPFOR  position  must  have  the  ability  to  control  up  to  ten  vehicles,  fidelity  in  terms  of 
TC-to-driver  commands  is  not  possible.  Nor  would  it  be  feasible  to  provide  joysticks  with  which  the  OPFOR 
player  would  control  the  movement  of  the  vehicles  individually  (because  of  the  time  that  would  be  necessary 
to  move  each  vehicle  individually).  Therefore,  the  OPFOR  position  must  have  the  capability  to  quickly 
identify  the  vehicle  he  wishes  to  move,  and  the  location  to  which  he  wishes  to  move  it.  SIMCAT  would  then 
initiate  the  movement,  control  its  movement  rate,  and  automatically  stop  the  vehicle  when  it  reached  the  point 
designated  by  the  OPFOR  position.  The  OPFOR  position  should  be  permitted  to  designate  movement  for 
several  vehicles  in  rapid  succession,  and  SIMCAT  should  initiate  the  movement  of  each  vehicle  immediately 


following  each  movement  command.  This  would  necessitate  that  SIMCAT  control  the  movement  of  several 
OPFOR  vehicles  simultaneously.  Aggregate  control  of  three,  possibly  more,  OPFOR  vehicles  (BMPs  and/or 
T72s)  should  be  considered. 


Perception 

The  OPFOR  position  must  be  cognizant  of  the  location  and  movement  of  each  of  the  vehicles  under  his 
control  at  all  times.  Line  of  sight  or  interviability  among  OPFOR  vehicles  is  not  of  concern. 


OPFOR  172  Tank  Turret  and  BMP  73MM  Gun/SAGGER  Movement 

As  was  the  case  for  trainees,  the  positioning  or  orientation  of  OPFOR  tanks  main  guns  and  BMPs  73mm 
gun/SAGGERs  are  critical  factors  which  must  be  considered  in  SIMCAT.  These  considerations  should  address 
direction,  rate,  control,  and  perception. 

Direction 


At  any  point,  the  turret  on  each  OPFOR  tank  and  the  gun  or  SAGGER  on  each  BMP  must  be  capable 
of  being  oriented  in  any  direction  (i.e.,  360°).  The  orientation  of  each  turret  and  gun  or  SAGGER  must  be 
capable  of  being  changed  at  any  time  whether  the  weapon  systems’  platforms  (i.e.,  a  tank  for  an  OPFOR  main 
gun  and  BMP  for  SAGGERs  or  73mm  gun)  are  moving  or  not 


Rate 

The  rate  of  orienting  or  moving  an  OPFOR  tank  turret  and  BMP  73mm  gun  or  SAGGER  is  irrelevant 


Control 

Manual  control  of  OPFOR  tank  turrets  and  BMP  73mm  gun  or  SAGGER  orientations  by  the  OPFOR 
position  is  neither  necessary  nor  desirable.  SIMCAT  should  automatically  orient  these  weapon  systems  in 
tactically  appropriate  positions.  In  other  words,  SIMCAT  should  assume  that  OPFOR  tank  main  guns  and 
BMP  73mm  guns  or  SAGGERs  are  properly  oriented  at  all  times. 


Perception 

If  it  is  assumed  that  all  OPFOR  tank  main  guns  and  BMP  weapon  systems  are  properly  oriented  at  all 
times,  there  is  no  need  to  cue  the  OPFOR  player  of  these  orientation  either  symbolically  or  by  any  other 


Conttoter/TnJoer  Movement  Requirements 


To  asress  tactical  situations  and  provide  proper  feedback  to  trainees,  die  controller/ trainer  must  always  be 
aware  of  what  is  moving,  at  what  speed  things  are  moving,  and  the  orientation  of  friendly  tank  main  guns.  This 
necessitates  that  SIMCAT  satisfy  the  following  functional  requirements: 
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Direction 
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The  controUer/trainer  must  be  aware  at  all  times  of  the  direction  of  movement  of  all  vehicles  (friendly 
and  OPFOR)  in  the  simulation.  In  addition,  the  controUer/trainer  must  always  be  aware  of  the 
directioo/orientatioo  of  the  main  gum  on  friendly  force  tanks. 


The  controUer/trainer  must  be  aware  of  the  movement  rate  of  each  vehicle  in  the  simulation  (see  section 
on  perception,  below). 


Control 

The  controUer/trainer  need  not  have  any  control  of  the  direction  of  movement  or  movement  rate  of  either 
OPFOR  or  friendly  forces,  nor  of  the  orientation  of  the  main  guns  on  friendly  force  tanks. 


Perception 


The  controUer/trainer  must  be  aware  of  the  foUowing  at  all  times: 

•  Vehicle  Orientation  —  The  front  of  all  friendly  and  OPFOR  vehicles  must  be  obvious  to  the 
controUer/trainer. 

•  Friendly  Force  Turret/Main  Gun  Orientation  —  The  position  of  the  main  guns  on  aU  friendly  force 
tanks  must  be  obvious  to  the  controUer/trainer.  This  need  not  be  accomplished  for  OPFOR  tank  main 
gum  or  other  OPFOR  weapon  systems  which  are  always  assumed  to  be  property  oriented. 

•  Movement  —  The  direction  in  which  any  simulation  vehicle  (i.e.,  friendly  tank  or  OPFOR  vehicle)  is 
moving  must  be  portrayed  to  the  controUer/trainer. 

•  Movement  Rate  —  The  movement  rate  of  any  simulation  vehicle  must  be  discemable  to  the 
controUer/trainer.  This  does  not  necessarily  dictate  that  all  movement  must  be  depicted  to  scale  nor 
depicted  in  continuous  motion.  For  example,  a  symbol  could  move  in  1/4  inch  increments  as  opposed 
to  moving  continuously  at  an  extremely  slow,  possibly  nondetectable,  rate.  However,  the  controller/ 
trainer  should  be  able  to  distinguish  rapid  from  slow  movement  rates. 
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DETECTION  /IDENTIFICATION 

These  functional  requirements  concern  the  relevant  objects,  events,  and  conditions  of  the  simulation 
environment  which  may  be  detected  and  subsequently  identified  by  each  participant  in  a  SIMCAT  simulation. 


*  •  •  • 

*  •  •  *  »  «  • 

»  •  * 
\  ,\ 


\V.y,  •%•%**.« 


/// 


These  functional  requirements  not  only  concern  what  can  be  seen  and  heard,  but  also  address  the  manner  in 
which  the  stimuli  are  to  be  represented  to  the  SIMCAT  positions.  In  general,  these  functional  requirements 
must  consider  the  detection  of  the  following: 

•  tanks  (Mis,  T72s) 

•  BMPs 

•  instantaneous  events  (weapons  signatures,  other  noises  and  flashes) 

•  transient  conditions  (smoke,  dust,  engine  noise). 

These  functional  requirements  must  also  address  bow  to  determine  when  detection  has  been  lost  by  each 
SIMCAT  position. 

It  should  be  noted  that  detection,  in  this  context,  is  not  restricted  to  detecting  only  opponent  forces  (i.e^ 
OPFOR  detecting  friendly  forces  and  friendly  forces  detecting  OPFOR  forces).  In  this  case,  detection  means 
that  friendly  forces  must  have  the  ability  to  detect  other  tanks  in  their  platoon  that  are  within  their  field  of 
vision;  and  in  the  case  of  the  OPFOR,  that  all  OPFOR  vehicles  must  be  represented  to  the  OPFOR  position 
at  all  times  regardless  of  line  of  sight  restrictions  between  OPFOR  vehicles.  However,  the  OPFOR  ability  to 
detea  friendly  forces  must  be  restricted  by  tine  of  sight  and  other  considerations. 

The  detection/identification  functional  requirements  for  SIMCAT  are  best  defined  in  terms  of  visual 
detection,  visual  identification,  auditory  detecdonTlocatioa,  and  representation  requirements. 


Visual  Detection 

To  determine  whether  an  OPFOR  or  friendly  force  vehicle  detects  something  visually,  two  questions 
must  be  answered — “Can  it  be  detected?”  and  “Do  they  see  it?”  To  answer  the  first  question,  SIMCAT  must 
determine  whether  or  not  line  of  sight  exists.  Terrain  characteristics1  (Le^  man-made  objects,  vegetation  and 
water,  and  relief)  located  between  the  friendly  or  OPFOR  simulation  vehicle  and  the  potentially  detectable 
object,  event,  or  condition  must  be  considered  in  determining  line  of  sight  If  line  of  sight  does  exist  the  range 
(Le^  distance  between  possible  detector  and  detectable  object)  must  be  considered  to  answer  the  second 
question  (“Do  they  see  it?”).  Many  variables  must  be  considered  to  determine  the  eflea  of  range  on  detection. 
These  would  indude  the  size  and  disposition  (i.e.,  stationary  or  moving)  of  die  detectable  object,  and  its 
persistence  (e*,  solid  object,  flash,  smoke,  eta),  all  of  which  are  mediated  by  the  possible  use  of  sighting 
devices.  With  respect  to  sighting  devices,  SIMCAT  must  always  assume  that  frieodly  forces  have  available  to 
them  both  binoculars  and  Thermal  Imagery  Sights  (TIS).  It  should  also  be  assumed  that  OPFOR  will  have 
binoculars  (but  not  TIS).  As  a  result,  the  magnification  capability  of  both  binoculars  and  TIS  must  be 
considered  at  ranges  which  normally  would  eliminate  any  possibility  of  detection  by  the  naked  eye.  Where 
smoke  exists,  SIMCAT  must  always  assume  that  friendly  forces  will  use  their  TIS  to  permit  them  to  see 
through  it 


Visual  Identification 

Once  the  system  has  considered  tine  of  sight  and  range,  and  has  determined  that  an  objea  can  be 
detected,  an  additional  question  must  then  be  asked — “What  does  he  see?"  Detection  does  not  necessarily 
mean  absolute,  100  percent  identification.  When  a  distant  objea  is  detectable  from  a  SIMCAT  vehicle,  the 
degree  to  which  it  can  be  identified  must  then  be  determined. 
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Three  variables  can  affect  the  degree  to  which  a  detected  object  can  be  identified  and  should  be 
considered  by  SIMCAT.  The  firtt  of  these  is  range.  For  example,  the  turret  of  a  tank  is  far  easier  to  identify  at 
a  range  of  300  meters  (with  or  without  visual  aids  such  as  binoculars)  than  it  would  be  at  1 100  meters.  The 
second  variable  is  the  distortion  associated  with  the  use  of  a  Thermal  Imagery  Sight  (TIS)  and  its  impact  on 
the  probability  of  identifying  a  detected  object  The  third  variable  is  the  presence  of  obscurants  such  as 
dissipating  smoke.  A  detected  object  seen  through  a  dissipating  smoke  screen  is  likely  to  be  more  difficult  to 
identify. 


Auditory  Detection/Locatioa 

Auditory  detection  requires  that  the  sound  source  be  within  range  of  a  possible  detector.  Range  or 
distance  from  the  possible  detector  is  not  the  only  variable  to  be  considered,  however.  The  noise  level  of  the 
environment  within  which  the  possible  detector  exists  (e-g^  a  tank  with  engine  running)  must  be  considered  as 
well  as  the  source  sound  level.  The  computation  used  to  determine  the  requirement  to  represent  an  auditory 
cue  should  also  consider  most  of  the  variables  previously  addressed  regarding  line  of  sight,  (e.g.,  terrain 
characteristics)  all  of  which  could  affect  noise  detection. 


Representation  Requirements 

Given  that  SIMCAT  has  determined  that  the  occupants  of  one  or  more  SIMCAT  vehicles  (OPFOR 
and/or  friendly)  have  visually  detected  something  (e^.,  vehicle  or  weapon  signature)  or  are  to  be  provided 
with  an  auditory  cue,  SIMCAT  must  represent  this  cue  in  some  way  to  the  appropriate  vehicle(s).  Specifically, 
these  cue  representation  requirements  are  as  follows: 

•  Auditory  —  Both  the  type  of  noise  (e^.,  running  engine,  explosion)  and  approximate  location  of  the 
noise  source  must  be  represented.  The  location  should  be  approximate  and  need  not  be  entirely 
accurate  because  it  is  extremely  difficult  to  determine  the  exact  direction  and  range  of  a  noise  source. 
Equally  important  to  representing  the  presence  of  an  auditory  cue  is  cueing  the  SIMCAT  participant 
when  the  noise  has  ceased. 

•  Location  of  Detected  Object,  Event  or  Condition  —  This  representation  requirement  is  twofold.  First, 
SIMCAT  must  designate  to  the  detector  the  location  of  the  object,  event  or  condition.  Second,  the 
system  must  represent  the  object,  event,  or  condition  itself  in  a  manner  which  permits  the  detector  to 
distinguish  it  to  some  degree. 

•  Identification  of  Object,  Event  or  Condition  —  SIMCAT  must  do  this  to  some  variable  level  of 
accuracy.  For  example,  SIMCAT  will  be  required,  no  doubt,  to  represent  a  T72  tank  in  several 
different  ways  depending  upon  conditions  (e.g.,  range,  presence  of  obscurants,  use  of  TIS).  A  fully 
exposed  T72,  seen  from  the  side  at  a  range  of  300  meters  through  binoculars,  would  be  represented  in 
an  entirely  different  manner  than  a  T72  detected  at  2000  meters  in  defilade  through  a  TIS.  In  the 
former  condition,  the  T72  would  probably  be  identifiable  as  a  T72  tank.  In  the  latter  condition,  it 
would  probably  be  identifiable  as  “some  type  of  vehicle.’’ 

•  Loss  of  Detection  —  SIMCAT  must  also  provide  some  form  of  notification  that  detection  of  an  object 
has  been  lost  or  degraded.  Examples  of  degraded  detection  would  be  a  tank  moving  at  a  rapid  rate 
away  from  the  detector,  or  a  dissipating  smokescreen  or  weapon’s  signature. 


All  of  the  cue  representation  requirements  listed  above  are  equally  applicable  to  all  SIMCAT  positions 
(i.e.,  trainees,  OPFOR,  and  controUer/trainer).  However,  the  OPFOR  and  controller/trainer  SIMCAT 
positions  have  additional  cue  representation  requirements  as  a  result  of  the  "God’s-eye”  perspective  to  be 
provided  to  each  of  these  positions. 

Specifically,  SIMCAT  must  not  only  provide  the  controller/trainer  and  OPFOR  positions  with 
detection/identification  cues,  it  must  also  designate  which  SIMCAT  vehide(s)  is  doing  the  detection.  For 
example,  the  single  individual  occupying  the  OPFOR  position  will  constantly  be  provided  with  representations 
of  all  OPFOR  vehicles  and  weapon  systems  involved  in  the  scenario  regardless  of  dispersion  and  intervisibility. 
Should  SIMCAT  determine  that  one  of  these  vehicles  (there  could  be  as  many  as  ten)  detects  an  object,  event, 
or  condition  and  the  other  vehicles  do  not,  a  problem  arises.  SIMCAT  must  represent  the  cue  in  some  manner 
to  the  OPFOR  position.  However,  before  the  OPFOR  position  can  take  any  action  (e.g.,  engage  the  object, 
take  evasive  action),  he  must  be  made  aware  of  the  specific  vehicles  that  have  detected  the  object.  Therefore, 
this  detection/detector  relationship  and  representation  requirement  becomes  critical 

A  somewhat  similar  detection/detector  relationship  problem  arises  in  the  controller/trainer  position.  If 
the  controUer/trainer  is  to  provide  complete  and  accurate  feedback,  he  must  know  who  sees  and/or  hears 
whatever  is  detected,  as  well  as  when  the  detection  occurs.  As  a  result,  the  detection/detector  relationship 
representation  must  be  provided  to  the  controUer/trainer  for  both  the  OPFOR  and  friendly  forces. 

Should  detection  from  an  OPFOR  vehicle  and/or  friendly  tank  be  distorted  as  a  result  of  TIS  usage, 
range,  and/or  the  presence  of  smoke,  the  controUer/trainer  representations  must  reflea  these  conditions. 

ENGAGEMENT 

The  purpose  of  the  engagement  functional  requirements  for  SIMCAT  is  to  resolve  aU  encounters  between 
the  military  vehicles  being  simulated  in  a  scenario.  An  encounter,  in  this  context,  is  defined  as  the  firing  of  one 
or  more  OPFOR  or  friendly  force  weapon  systems.  Engagement  functional  requirements  involve  five  basic 
requirements.  First,  SIMCAT  should  model  the  operational  characteristics  associated  with  the  use  of  various 
weapon  systems,  including  variables  such  as  reload  times.  Second,  SIMCAT  should  model  the  potential  effects 
resulting  from  the  use  of  weapon  systems  including  vehicle/equipment/weapon  system  damage  and 
destruction,  personnel  kills,  and  suppression.  Third,  the  effects,  if  any,  of  a  successful  engagement  by  a  weapon 
system  (Le.,  a  hit)  must  be  represented  to  the  different  SIMCAT  positions  (Le.,  controUer/trainer,  OPFOR,  and 
trainees)  with  varying  degrees  of  specificity.  For  example,  if  one  tank  engages  another  and  obtains  a  direct  hit, 
the  tank  that  was  hit  certainly  would  know  that  his  turret  is  no  longer  functioning,  while  the  tank  firing  the 
round  would  not  necessarily  be  aware  of  this  fact  Fourth,  the  detectable  events  and  conditions  created  as  a 
result  of  a  weapon  system  firing  (i.e.,  weapon  signature,  impact  of  munitions)  must  be  represented  to  the 
appropriate  SIMCAT  positions.  Fifth,  SIMCAT  must  maintain  an  audit  of  the  amount  of  munitions  expended 
by  each  weapon  system. 

SIMCATs  engagement  functional  requirements  can  be  specified  best  by  addressing  each  of  the  following: 

•  Weapon  Systems  Involved 

•  Control  of  Ml  Abrams  Weapon  Systems 

•  Control  of  OPFOR  Weapon  Systems 

•  Weapon  Effects  Modeling 

•  Representation  Requirements 


Weapon  Systems  Involved 


One  of  the  most  critical  factors  or  variables  that  must  be  considered  in  the  development  of  engagement 
modeling  and  representation  processes  is  the  weapon  system  involved.  In  the  initial  version  of  SIMCAT,  there 
will  only  be  a  few  weapon  systems  although  the  number  can  easily  be  increased  at  a  future  date.  The  weapon 
systems  and  their  associated  basic  loads  are  specified  in  the  table  below: 


Table  1 

SIMCAT  Woapon  Systems  and  Their  Associated  Basic  Loads 


WEAPON  SYSTEM 

BASIC  LOAD 

Friendly  Forces  (i.e.,  Ml  Tank): 

Coax 

10,000  rounds  (every  5th  round  a  tracer) 

Main  Gun 

33  rounds  APFSOS  (735  series  or  up) 
22  rounds  HEAT 

Mines 

4  AT.  Mines 

OPFOR  (i.e.,  T72  and  BMP): 

T72  Main  Gun 

40  rounds  HAVAPFSDS 

SAGGER  (mounted  on  BMP) 

4  rounds 

73mm  Gun  (on  BMP) 

40  rounds  (assume  all  are  HEAT) 

Mines 

Type  and  number  to  be  determined 

The  basic  loads  specified  in  Table  1  for  each  weapon  system  represent  the  maximum  number  and  type  of 
rounds  that  should  be  allocated  for  that  weapon  system.  While  the  controiler/trainer  should  not  be  able  to 
increase  these  numbers  in  any  scenario,  he  should  be  permitted  to  decrease  them  if  he  desires  to  do  so. 


Control  of  Ml  Abrams  Weapon  Systems 

Each  SIMCAT  Trainee  position  will  have  total  control  of  the  tank  weapon  systems  at  that  position.  An 
Ml  tank  has  four  weapon  systems  aboard:  the  tank  main  gun.  a  coax  machinegun,  a  .50  caliber  machinegun, 
and  the  loader’s  7.62  machinegun.  Only  the  tank  main  gun  and  the  coax  machinegun  will  be  simulated  in 
SIMCAT.  On  an  Ml  tank,  the  main  gun  and  coax  can  be  fired  by  either  the  gunner  or  the  TC.  In  SIMCAT, 
however,  only  the  gunner1  will  be  permitted  to  fire  these  weapons. 

Given  that  only  the  tank  commander  will  be  present  during  a  simulation,  SIMCAT  has  certain  Ml 
weapon  system  control  functional  requirements  it  must  satisfy.  These  requirements  can  be  defined  most  easily 
by  addressing  the  tank  main  gun  and  coax  collectively. 

•  Control  of  Tank  Main  Gun  and  Coax  —  Both  the  tank  main  gun  and  coax  can  be  controlled  by  either 


number  of  ways  (e^,  voice  synthesis/  recognition,  function  keys,  screen  menus  with  keyboard  inputs, 
textual  input/output).  It  is  highly  desirable  that  voice  synthesis/recognition  technologies  be  employed. 
This  is  the  only  alternative  that  will  provide  the  fidelity  necessary  to  achieve  training  objectives.  For  the 
remaining  discussion  of  this  functional  requirement,  it  is  irrelevant  which  technology  will  eventually  be 
used.  If  voice  technology  is  used,  it  can  be  assumed  that  sending  messages  Grom  the  gunner  to  the  TC 
will  involve  voice  synthesis.  If  voice  technology  is  not  used,  it  can  be  assumed  that  a  textual  output  on 
a  CRT  will  be  used. 

Once  a  trainee  has  identified  a  target  he  wishes  to  engage  with  either  the  coax  or  the  main  gun,  SIMCAT 
must  first  allow  the  trainee  to  traverse  the  turret  so  that  the  main  gun,  and  coax  are  pointed  in  the  general 
direction  of  the  target  (this  functional  requirement  is  addressed  in  detail  in  the  discussion  of  SIMCATs 
movement  functional  requirements).  Once  this  has  been  accomplished,  SIMCAT  must  accommodate  (through 
voice  recognition/synthesis,  function  keys/textual  output,  etc.)  a  series  of  trainee  gunner  and  loader 
commands.  The  sequence  of  commands  and  the  functional  requirements  related  to  them  are  as  follows: 


—  TC  Provides  Alert  to  Gunner  —  The  TC  will  call  out  “Gunner!”  over  the  tank  intercom.  This  alert 
normally  is  provided  at  the  same  time  the  TC  is  traversing  the  turret  in  the  general  direction  of  the 
target  The  purpose  of  the  command  is  to  alert  the  gunner  that  the  TC  wants  him  to  engage  a 
target 

—  TC  Identifies  Weapon  System  to  Engage  —  The  gunner,  having  been  alerted  that  he  should 
prepare  to  engage  a  target  now  must  be  told  which  weapon  system  (coax  or  main  gun)  he  should 
use  to  engage  the  target  If  the  TC  wants  the  gunner  to  engage  the  target  with  the  coax,  the  TCs 
next  command  over  the  tank  intercom  will  be  simply,  “Coax!”.  If  the  TC  wants  the  gunner  to 
engage  the  target  with  the  tank  main  gun,  the  TCs  next  command  over  the  tank  intercom  will  be 
either  “HEAT!”  or  "SABOT!”  specifying  which  of  the  two  types  of  tank  main  gun  rounds  should 
be  used.  This  command  will  actually  be  directed  at  the  loader  who  will  load  the  round  specified. 

—  TC  Describes  Target  —  The  TC  will  then  describe  over  the  tank  intercom  the  target  to  be  engaged 
(e.g.,  "Tank’*,  “BMP").  SIMCAT  need  not  recognize  the  target  description  given  by  the  TC  because 
SIMCAT  will  be  controlling  the  gunner  actions  and  will  be  aware  of  what  the  TC  has  detected. 
Therefore,  SIMCAT  can  ignore  this  portion  of  die  firing  command. 


—  Loader  Announces  Message  —  Next,  the  loader  will  announce  ”Up!”  when  the  round  has  been 
loaded.  SIMCAT  must  provide  this  message  to  the  trainee  (over  the  tank  intercom,  if  voice 
synthesis  is  used). 


—  Gunner  Announces  Message  —  SIMCAT  must  then  provide  the  message  “Identified”  Grom  the 
gunner  to  the  TC  (over  the  voice  intercom  if  voice  synthesis  is  used). 


—  TC  Gives  Fire  Command  —  Once  the  loader  has  said  “Up”  and  the  gunner  has  said  “Identified”, 
the  TC  will  give  the  command  “Fire!”.  At  this  point,  SIMCAT  should  cause  the  tank  main  gun  or 
coax  (depending  on  the  weapon  system  specified  by  the  TC  earlier)  to  fire. 


Gunner  Gives  Fire  Response  to  TC  —  If  the  tank  main  gun  is  to  be  fired,  SIMCAT  must  output 
the  message  “On  the  Way!”  Grom  the  gunner  to  the  TC  over  the  tank  intercom. 

Subsequent  Firing  Activity  —  At  this  point  during  a  tank’s  main  gun  firing,  several  activities  are 
possible,  depending  upon  certain  conditions  (e.g.,  whether  or  not  the  round  hits  its  target,  whether 
or  not  the  gunner  can  see  the  round  impacting  down  range).  In  SIMCAT,  the  conditions 
subsequent  to  main  gun  firing  will  be  held  constant.  Specifically,  it  will  always  be  assumed  that  the 
gunner  can  see  the  target  and,  when  a  HEAT  round  has  missed,  that  the  gunner  will  always  be  able 


to  determine  if  the  round  was  short,  long,  or  to  the  left  or  right  of  the  target  being  engaged,  but  not 
when  a  SABOT  round  has  missed  since  it  cannot  be  detected.  Given  that  these  conditions  will  be 
held  constant,  there  no  longer  will  be  any  requirement  for  the  TC  to  communicate  with  the  gunner 
or  loader.  However,  the  gunner  will  have  to  provide  feedback  to  the  TC.  This  feedback  will  vary 
depending  on  whether  or  not  the  target  was  hit,  as  in  the  following  situations: 

-  If  the  target  was  hit,  the  gunner  (i.e.,  SIMCAT)  will  tell  the  TC  “Target”  over  the  tank  intercom. 

-  If  the  target  was  missed,  the  gunner  (i.e.,  SIMCAT)  will  tell  the  TC  “Re-engaging.”  Given  that 
the  gunner  will  always  be  presumed  to  have  seen  the  target  and  the  relationship  of  the  target  to 
the  area  where  his  missed  round  impacted,  the  gunner  will  fire  automatically  at  the  target  once 
again.  This  will  continue  until  the  target  is  hit 

NOTE:  If  a  target  disappears  (e.g.,  moves  out  of  sight),  SIMCAT  should  automatically  cease  all 
gunner  activities.  In  addition,  the  TC  should  be  able  to  issue  a  “Cease  Fire”  command  to  the 
gunner  to  signify  that  he  wishes  the  gunner  to  stop  firing. 

Control  of  OPFOR  Weapon  Systems 

The  individual  occupying  the  SIMCAT  OPFOR  position  will  be  provided  at  all  times  with 
representations  of  the  location  and  movement  of  all  OPFOR  vehicles  as  specified  in  the  sections  on  SIMCAT 
movement,  terrain,  and  detection/identification  functional  requirements.  It  is  this  condition  that  dictates  most 
of  the  functional  requirements  associated  with  the  control  of  OPFOR  weapon  systems  (which  differ 
considerably  from  the  functional  requirements  for  friendly  force,  i.e.,  Ml  Abrams  weapon  system  control). 
Specifically,  SIMCAT  must  provide  the  OPFOR  position  the  capability  of  either  manually  controlling  the 
weapon  systems  of  OPFOR  vehicles  or  allowing  SIMCAT  to  control  OPFOR  weapon  system  firings 
automatically.  Manual  weapon  system  control  would  necessitate  the  following  functional  requirements: 

•  Identification  of  Weapon  Platform  to  Use  —  Given  that  the  OPFOR  position  will  have  represented  to 
him,  at  all  times,  the  location  of  all  his  weapon  system  platforms  (i.e.,  BMPs  and  T72s)  as  well  as 
anything  detected  (i.e.,  potential  targets)  by  each  platform,  he  must  have  the  ability  to  identify  which 
weapon  platform  he  wishes  to  fire. 

•  Identification  of  Weapon  System  —  As  stated  previously,  two  weapon  platforms  will  be  involved  in 
the  OPFOR  forces — T72  tanks  and  BMPs.  Only  one  T72  tank  weapon  system  will  be  simulated — its 
main  gun.  Therefore,  when  the  OPFOR  position  selects  a  T72  as  the  weapon  platform  he  wishes  to 
fire,  it  will  always  be  its  main  gun  that  fires.  However,  should  the  OPFOR  position  select  a  BMP  as  the 
weapon  platform  to  engage  a  target,  there  are  two  weapon  systems  that  could  fire — a  73mm  gun  and  a 
SAGGER.  Therefore,  whenever  the  OPFOR  position  identifies  a  BMP  as  the  weapon  platform  to 
engage,  SIMCAT  must  also  permit  him  to  select  which  weapon  system(s)  on  board  the  BMP  he  wishes 
to  fire — the  73mm  gun,  the  SAGGER,  or  both. 

•  Target  Identification  —  At  any  time,  a  single  OPFOR  vehicle  (i.e.,  T72  or  BMP)  may  have 
simultaneous,  multiple  target  opportunities.  In  addition,  since  all  OPFOR  vehicles  will  be  represented 
to  the  OPFOR  position  along  with  anything  that  may  be  detected  from  each  OPFOR  vehicle,  one 
must  anticipate  die  possibility  that  an  OPFOR  position  may  misinterpret  SIMCAT  cues  and  select  a 
weapon  platform  to  engage  a  target  that  could  not  be  detected  from  that  weapon  platform.  This  could 
happen,  for  example,  when  two  OPFOR  vehicles  are  in  close  proximity.  A  target  is  detected  from  one 
OPFOR  vehicle  which  the  SIMCAT  appropriately  represents  to  the  OPFOR  position.  The  OPFOR 


position  could  mistakenly  interpret  this  cue  and  specify  that  he  wishes  the  OPFOR  vehicle  which  did 
not  detea  the  target  to  engage  it  SIMCAT  must  permit  the  OPFOR  position  to  identify  the  target  that 
be  wishes  to  engage.  If,  as  a  result  of  misinterpreting  SIMCAT  cues,  the  OPFOR  position  associates  the 
target  with  a  weapon  system  that  has  not  detected  the  target  identified  by  the  OPFOR  position, 
SIMCAT  must  provide  the  OPFOR  with  appropriate  feedback. 

Once  a  battle  begins,  the  OPFOR  position  may  have  difficulty  tracking  each  of  his  individual  vehicles 
and  associated  weapon  systems.  Therefore,  SIMCAT  must  have  the  capability  to  automatically  fire  the 
OPFOR  weapon  systems  should  the  OPFOR  position  desire  SIMCAT  to  do  so.  This  simply  means  that 
SIMCAT  should  perform  the  fire  control  processes  without  requiring  the  OPFOR  player  having  to  cue  the 
system  to  do  so  (Le.,  when  an  OPFOR  vehicle  detected  a  target,  it  would  automatically  engage  the  target  with 
the  most  appropriate  weapon  system  after  an  appropriate  time  delay).  The  OPFOR  position  should  be  capable 
of  designating  “automatic  fire  control”  for  a  single  or  for  multiple  OPFOR  vehicles.  He  should  also  be 
permitted  to  switch  from  automatic  to  manual  fire  control  whenever  he  desires  to  do  so. 


Weapon  Effects  Modeling 

The  functional  requirements  for  weapon  effects  can  be  viewed  as  consisting  of  two  major  processes: 
determination  of  single  weapon  effects  and  determination  of  aggregate  weapon  effects.  Each  will  be  discussed 
individually. 

When  one  or  more  weapon  systems  engage  a  single  target,  SIMCAT  must  determine  the  effects  of  the 
weapon  system(s)  firing  on  the  target  engaged.  Two  subprocesses  are  involved — hit  probabilities  and,  if  the 
target  is  hit,  consequential  damage  to  the  target  At  a  minimum,  hit  probabilities  must  consider  the  following 
variables: 

•  Distance  to  target 

•  Type  of  target  (e.g.,  “hard”  or  “soft”) 

•  Target  disposition  (e.g.,  stationary  or  moving,  fully  or  partially  exposed,  front/ rear/side  view) 

•  Presence  (and  degree  of)  or  absence  of  obscurants  (e.g.,  smoke,  dust) 

•  Finer  disposition  (e.g.,  stationary  or  moving,  using  TIS). 

After  having  determined  whether  or  not  the  target  was  hit  SIMCAT  must  next  determine  what  damage, 
if  any,  the  target  suffered  as  a  result  It  should  not  be  assumed  that  a  target  is  destroyed  anytime  it  is  hit.  For 
example,  an  Ml  tank  that  receives  several  direct  hits  from  a  73mm  gun  on  a  BMP  would  not  be  destroyed  in 
most  cases.  However,  the  possibility  does  exist  that  the  mobility  of  the  tank  may  be  affected  if  a  road  wheel  is 
damaged  or  destroyed  or  if  a  track  is  thrown.  Therefore,  SIMCAT  must  consider  the  following  variables  to 
determine  the  extent  of  damage  to  the  target  that  has  been  hit: 

•  Ballistics  of  impacting  munitions  (e.g.,  HEAT  main  gun  round,  point  detonating  155mm,  73mm 
HEAT) 

•  Number  of  rounds  impacting  (e.g.,  single  main  gun  HEAT  round,  three  73mm  HEAT  rounds,  20  coax 
rounds) 

•  Number  of  weapon  systems  engaging  target  (e.g.,  two  Ml  tanks  may  simultaneously  engage  a  T72  or 
BMP) 

•  Target  vulnerability  (e.g.,  the  target’s  mobility,  turret,  communications  capability) 

•  Target  type  (e.g.,  type  of  armor,  wheeled  or  tracked) 


In  addition  to  determining  single  weapon  effects,  a  set  of  force-on-force  aggregate  models  may  be  required 
to  handle  larger  scale  engagements  while  minimizing  processing  requirements.  Such  a  condition  may  occur  in 
an  intensified  situation  where,  for  example,  three  Ml  tanks  and  two  BMPs  suddenly  are  exposed  to  one 
another  simultaneously.  Should  such  a  situation  occur,  it  may  be  beyond  the  processing  capability  of  SIMCAT 
to  handle  simultaneous  firing  commands  from  three  Ml  tanks  and  two  BMPs,  process  hit  probabilities,  and 
determine  damage  to  targets  hit  Another  example  where  aggregate  models  definitely  will  be  required  is  with 
impacting  artillery,  where  the  number  of  targets  within  a  sheath  and  number  of  impacting  rounds  must  be 
considered. 

The  use  of  aggregate  models  for  weapon  effects  requires  SIMCAT  to  compute  not  only  the  results  of 
engagements,  but  also  their  duration.  After  determining  the  expected  duration  and  the  loss  rates  over  time  at 
the  start  of  a  force-on-force  engagement,  SIMCAT  must  allow  for  the  possibility  that  intervening  events  affect 
the  outcome.  Specifically,  this  allows  the  SIMCAT  OPFOR  and  trainee  positions  to  take  some  sort  of  action, 
such  as  attempting  to  disengage,  withdrawing,  or  possibly  requesting  indirect  fire  support  rather  than  simply 
being  forced  to  accept  a  predetermined  outcome  for  the  engagement 

Representation  Requirements 

The  controller/trainer,  trainee,  and  OPFOR  engagement  representation  requirements  for  SIMCAT  are 
functionally  identical,  but  they  will  vary  dramatically  in  the  manner  in  which  they  are  satisfied.  Therefore,  the 
engagement  representation  requirements  will  be  discussed  first  in  terms  of  their  functions  that  will  be  common 
to  all  SIMCAT  positions.  Following  that,  the  differences  in  the  manner  in  which  engagement  representations 
will  be  satisfied,  depending  on  the  SIMCAT  position  involved,  will  be  addressed. 

The  engagement  representation  requirements  for  SIMCAT  fall  into  three  basic  categories  —  weapon 
firing,  impact  of  weapon  rounds,  and  effect,  if  any,  of  impacting  rounds.  Specifically,  these  requirements  dictate 
that  SIMCAT  represent  the  following: 

•  The  weapon  platform  that  is  firing  —  The  system  must  indicate  whether  a  BMP,  T72,  or  Ml  tank  is 
firing. 

•  The  weapon  system  aboard  the  platform  that  is  firing  —  The  system  must  indicate  whether  it  is  the 
coax  or  main  gun  that  is  being  fired  at  a  Ml  tank,  and  whether  it  is  the  SAGGER  or  the  73mm  gun 
that  is  being  fired  at  a  BMP.  In  the  case  of  the  172,  it  will  always  be  assumed  that  the  main  gun  is  being 
fired. 

•  The  impact  of  weapon  system  rounds  —  Auditory  and  visual  cues  resulting  from  rounds  impacting 
down  range  will  be  provided  to  appropriate  SIMCAT  positions.  The  positions  will  include  not  only  the 
weapon  system  that  fired,  but  any  friendly  and  OPFOR  vehicles  that  can  detea  the  impacting  rounds. 

•  Weapon  signatures  —  SIMCAT  must  provide  appropriate  auditory  and  visual  cues  to  all  SIMCAT 
vehicles  that  could  detea  the  signature  of  a  weapon. 

•  Weapon  firing  —  As  appropriate,  SIMCAT  positions  must  be  made  aware  of  when  one  of  their 
weapon  systems  has  initiated  firing  and  when  it  has  ceased  firing. 

•  In-flight  representations  —  Cues  resulting  from  tracers  and  SAGGER  ATGMs  in  flight  must  be 
represented  to  appropriate  SIMCAT  positions  (providing  cues  not  only  to  the  individual  who  fires  the 
weapon,  but  to  those  individuals  who  could  detea  such  cues). 


•  Weapon  effects  —  SIMCAT  positions  should  receive  visual  and  auditory  cues  that  would  result  from 
the  impact  of  the  round  or  missile  (e.g.,  burning  BMP,  T72  being  blown  up,  round  impacting 
short/long/left/ right).  This  requirement  should  not  be  interpreted  to  mean  that  the  actual  weapon 
effect(s)  would  be  divulged  to  a  SIMCAT  position.  For  example,  should  a  HEAT  round  hit  but  not 
penetrate  a  tank  turret,  the  resulting  cue  would  probably  be  restricted  to  a  flash,  a  bang,  and  some 
smoke  in  the  proximity  of  the  turret  that  was  hit  If  the  turret  is  frozen  as  a  result  of  the  hit  only  the 
occupants  of  the  tank  that  was  hit  not  the  position  firing  the  HEAT  round,  would  be  aware  of  this 
consequence. 

Given  that  each  SIMCAT  positions  will  have  a  different  perception1  of  the  battlefield,  the  manner  in 
which  engagement  representations  will  be  provided  to  each  position  will  vary.  For  example,  consider  the 
engagement  representation  requirements  for  the  Ml  tank.  SIMCAT  must  represent  the  Ml  weapon  system  that 
is  firing  (Le.,  coax  or  tank  main  gun).  SIMCAT  will  represent  this  differently  to  each  SIMCAT  position  in  the 
following  ways: 

•  Trainee  Position  —  SIMCAT  will  probably  provide  varying  auditory  cues  to  represent  which  of  the 
Ml  weapon  systems  is  firing.  Visual  representations  of  rounds  in-flight  (i.e.,  tracers  from  the  coax), 
impacting  rounds,  and  weapon  effects  (e.g.,  dust,  primary  and/or  secondary  explosions,  fire,  smoke)  will 
be  provided  to  the  trainee  from  the  perspective  of  the  tank  itself. 

•  Controller/Trainer  Position  —  The  controller/trainer  will  never  need  to  be  provided  with  auditory  cues 
resulting  from  the  firing  of  a  Ml  tank.  Nor  will  the  controller/trainer  need  to  be  provided  with  visual 
representations  from  the  perspective  of  the  Ml  tank  actually  firing.  However,  the  controller/trainer  will 
need  representations  which  will  enable  him  to  determine  which  of  the  four  Ml  tanks  is  firing  and  which 
weapon  system  is  being  fired  (Le.,  coax  or  main  gun).  Unlike  the  trainee  whose  tank  is  firing,  the 
controller/trainer  does  not  need  the  auditory  nor  ground  level  perception  representations  of  these 
conditions.  Instead,  these  conditions  may  be  represented  symbolically. 

•  OPFOR  —  The  OPFOR  position  in  this  example  would  be  provided  with  appropriate  visual  and 
auditory  cues  depending  upon  the  detection/identification  variables  discussed  previously.  When  an 
OPFOR  vehicle  engages  a  target  (Le^  with  a  T72  main  gun  or  with  either  a  73mm  gun  or  SAGGER 
from  a  BMP),  engagement  representations  to  the  OPFOR  positions  should  be  quite  different  from  those 
provided  to  a  trainee  position  when  a  Ml  weapon  system  fires.  SIMCAT  will  portray  all  of  the 
OPFOR  vehicles  simultaneously.  Therefore,  when  an  OPFOR  vehicle  engages  a  target,  SIMCAT  must 
represent  to  the  OPFOR  position  which  weapon  platform  is  firing  (i.e.,  which  BMP  or  T72)  and,  if  it  is 
a  BMP,  whether  the  SAGGER  or  73mm  gun  is  firing.  These  representation  requirements  may  be 
satisfied  through  some  form  of  symbology.  The  approach  used  to  make  these  representations  to  the 
OPFOR  position  would  also  satisfy  the  controller/trainer  OPFOR  engagement  representation 
requirements. 


INDIRECT  FIRE 

Dedicated  indirect  fire  support  will  be  provided  to  both  friendly  (i.e.,  155mm)  and  OPFOR  (i.e.,  152mm) 
forces  in  all  SIMCAT  scenarios.  To  satisfy  its  indirect  fire  functional  requirements,  SIMCAT  must  maintain  a 


‘Perception  of  the  battlefield  from  the  trainee  potition  will  be  restricted  to  a  view  from  a  siii|te  Ml  taut  perception  from  the  OPFOR  position  will 
be  a  bird's-eye  view  of  all  of  his  vehicles;  and  perception  from  the  controUer/traioee  position  will  be  a  view  of  the  entire  battlefield  and  will  include  all 
OPFOR  and  friendly  vehicles  involved. 


record  of  indirect  fire  allocations,  provide  a  means  for  both  the  friendly  and  OPFOR  forces  to  request  indirect 
fire  support,  deliver/ impact  indirect  fires,  and  represent  the  effects  of  indirect  fire  to  all  SIMCAT  positions. 
Each  of  these  requirements  will  be  discussed  individually. 
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Fire  Support  Allocations 

No  weapon  system  found  on  the  battlefield  has  an  inexha ustable  supply  of  munitions.  As  a  result,  weapon 
system  usage  should  be  tempered  and  controlled.  These  are  difficult  skills  to  teach  and  to  learn  because  soldiers 
tend  not  to  be  concerned  with  such  matters  in  combat  However,  this  is  a  reality  of  combat  that  SIMCAT  must 
address  if  it  is  to  avoid  negative  training. 

In  a  real  tactical  situation,  the  only  information  provided  to  tactical  or  maneuver  unit  leaders  regarding 
indirect  fire  is  whether  or  not  it  exists;  if  it  does  exist,  whether  or  not  it  is  dedicated  support;  and  the  number  of 
batteries  supporting  them.  The  point  here  is  that  the  leaders  are  never  informed  of  the  number  of  rounds  that 
are  available  for  their  support  However,  the  number  of  rounds  available  is  restricted  minimally  to  the  basic 
load  of  the  batteries  supporting  them.  Therefore,  SIMCAT  must  place  a  ceiling  on  the  number  of  rounds,  by 
fuze  type,  that  are  available  to  support  both  the  OPFOR  and  friendly  forces.  This  allocation  will  never  be 
provided  in  total  to  either  the  OPFOR  or  friendly  forces.  However,  SIMCAT  will  monitor  the  numb*,  of 
rounds  fired  and  the  number  of  rounds  remaining.  When  the  supply  has  been  exhausted,  SIMCAT  will  make 
appropriate  notifications  (for  example,  to  the  controller/trainer  as  well  as  to  TC,  that  all  of  his  artillery 
allocation  has  been  exhausted). 

It  is  difficult  to  determine  the  number  of  rounds  by  fuze  type  that  should  be  allocated  to  OPFOR  and 
friendly  forces.  Many  variables  must  be  considered,  including  number  of  batteries  in  support,  size  of  artillery 
(e.g.,  155mm,  105mm),  basic  loads,  mission  of  maneuver  units  being  supported,  and  combat  conditions 
experienced  to  date  by  both  supporting  artillery  and  maneuver  units  involved.  Most  military  personnel  would 
agree  that  it  is  difficult,  if  not  impossible,  to  identify  any  norm(s)  considering  the  number  of  variables  involved 
and  their  permutations.  However,  the  idea  of  an  inexhaustable  supply  of  indirect  fire  support  is  unrealistic. 
Therefore,  ceilings  on  the  number  of  rounds  available  by  fuze  type  must  be  established  for  SIMCAT.  These  are 
specified  in  Table  2  below. 


Table  2 

Indirect  Fire  Support  Allocations  by  Fuze  Type,  Mission,  and  Force 


Numbar  of  Round*  Allocated  by  Fitandly  Fore*’*  Mission 

FuaaTypo 

MOVMMflt  tO 

Contact 

Hasty  Attack 

Catena* 

Friendly  (155mm): 

DPICM 

60 

60 

40 

White  Phosphorous 

24 

24 

20 

OPFOR  (152mm): 

High  Explosive,  Quick 

50 

50 

200 

White  Phosphorous 

None 

None 

35 

26 
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The  allocations  specified  in  Table  2  are  the  maximum  number  of  rounds  that  OPFOR  and  friendly  forces 
can  be  allocated  during  any  scenario.  Hie  controOer/trainer  will  have  the  capability  to  decrease  the  allocations 
as  he  sees  fit  during  initialization  of  the  simulation,  but  will  not  be  permitted  to  allocate  more  artillery  than  that 
specified  in  the  table. 


Friendly  Force  Indirect  Fire  Requests 

Armor  platoon  leaders  normally  request  indirect  fire  support  in  one  of  two  ways:  either  by  direct  contact 
with  a  Fire  Direction  Center  (FDC)  using  formal  call  for  fire  procedures,  or  through  communications  with  a 
Fire  Support  Team  Forward  Observer  (FIST  FO)  assigned  to  Ids  company  team.  In  the  latter  case,  formal  call 
for  fire  procedures  are  not  required  and  communications  are  not  regimented  by  sequencing  or  content 
protocols.  The  initial  version  of  SEMCAT  will  not  concern  itself  with  platoon  leader/FDC  call  for  fire.  All 
indirect  fire  support  requests  will  be  handled  through  communications  between  the  platoon  leader  and/or  the 
platoon  sergeant  and  a  FIST  FO.  To  define  the  functional  requirements  associated  with  friendly  force  indirect 
fire  support,  two  areas  will  be  addressed.  The  first  area  is  concerned  with  the  requirements  associated  with 
requesting  an  indirect  fire  mission.  Hie  second  is  the  manner  in  which  the  requests  are  actually  processed. 

•  Indirect  Fire  Requests  —  When  either  the  platoon  leader  or  the  platoon  sergeant  decides  to  request  an 
indirect  fire  mission,  he  first  will  establish  contact  with  the  Company  Team’s  FIST  FO.  This  will  be 
done  on  the  Company  Team  Net  The  role  of  the  FIST  FO  will  be  assumed  by  the  SIMCAT 
controller/trainer. 

It  will  always  be  assumed  that  the  FIST  FO  can  observe  the  target  that  the  platoon  leader  or  platoon 
sergeant  is  attempting  to  engage  with  indirect  fire.1  Therefore,  when  an  indirect  fire  request  is  made,  the 
platoon  leader  or  platoon  sergeant  need  only  identify  the  target  and  specify  its  location  by  providing  a 
Spot  Report  to  the  FIST  FO  on  the  company  net,  ending  with  a  request  for  indirect  fire.  In  a  real 
situation,  formal  call  for  fire  requests  communicated  to  a  FDC  would  then  become  the  responsibility  of 
the  FIST  FO.  In  addition,  the  FIST  FO  would  make  any  subsequent  adjustments  necessary  to  get  the 
indirect  fire  on  target  These  adjustments  do  not  (and  in  SIMCAT,  will  not)  require  any 
communications  between  the  platoon  leader  or  platoon  sergeant  and  the  FIST  FO. 

Given  that  the  controller/trainer  will  assume  the  role  of  the  FIST  FO,  it  will  be  his  responsibility  to 
ensure  the  indirect  fire  request  received  from  the  platoon  leader  or  platoon  sergeant  is  properly 
processed. 

•  Request  Processing  —  Having  received  an  indirect  fire  request  from  either  the  platoon  leader  or  platoon 
sergeant,  the  controller/trainer  (acting  as  the  FIST  FO)  will  be  responsible  for  actually  processing  the 
request  Therefore,  the  controller/ trainer  must  be  able  to  specify  the  following  to  the  system: 

—  coordinates  or  adjustments 

—  fuze  type 

—  direction  (in  mils) 

—  number  of  batteries  or  rounds  to  be  fired. 


'Thb.  in  bet.  will  be  tbt  cm*  becaure  the  cootroUtr/tmner  (actus  •*  the  FIST  FO)  will  have  a  birdVeye  view  of  the  battle.  Therefore,  the 
controller/ oaiaer  will  be  capebie  of  accurately  unerpredna  piatooa  requea  made  by  the  piatooa  leeder  or  the  piatooa  rerptat. 


It  is  not  being  suggested  that  formal  call  for  fire  procedures  be  established  between  the  controiler/trainer 
and  SIMCAT.  To  the  contrary,  the  simplest  and  most  expedient  means  of  conveying  this  information  to 
SIMCAT  is  necessary  to  avoid  overburdening  the  controller/trainer.  The  use  of  light  pens  or  touch-sensitive 
screens  would  be  ideal,  but  may  not  be  feasible  considering  SIMCAT  cost  constraints.  Other  alternatives  which 
would  expedite  the  input  of  indirect  fire  data  would  include  the  use  of  “fill-in-the-blank”  forms  or  menus 
depicted  on  the  controller/trainer  screen  (monitor).  Another  way  to  expedite  this  process  would  be  to  include 
grid  lines  on  the  controller/trainer  terrain  representations.  These  alternatives  should  be  among  those  identified 
and  considered. 

Given  the  likelihood  that  the  controller/trainer  will  be  overburdened  with  processing  indirect  fire  requests 
(especially  adjustments  following  an  initial  request),  it  will  be  necessary  for  SIMCAT  to  automatically  make 
any  adjustments  following  an  initial  request  for  fire  input  to  SIMCAT  by  the  controller/trainer.  SIMCAT  will 
be  able  to  do  this  because  it  will  know  where  the  indirect  fire  targets  are,  where  the  initial  request  impacted, 
and,  therefore,  what,  if  any,  subsequent  adjustments  are  necessary.  SIMCAT  must  also  consider  and  reflect  any 
time  delays  associated  with  adjustments  and  the  human  inaccuracies  associated  with  such  adjustments  (e.g., 
seldom,  if  ever,  would  the  initial  adjustment  result  in  the  indirect  fire  impacting  directly  on  the  target — 
especially  if  it  is  moving). 


OPFOR  Indirect  Fire  Requests 

Given  that  there  are  no  training  objectives  associated  with  the  OPFOR,  the  fidelity  of  the  procedures 
associated  with  requesting  indirect  fire  support  is  of  no  concern.  In  addition,  because  there  is  concern  about 
limiting  the  procedural  burdens  placed  on  the  controiler/trainer,  the  manner  in  which  the  OPFOR  requests 
indirect  fire  support  will  differ  greatly  from  the  way  the  friendly  forces  request  indirect  fire  support. 

The  individual  occupying  the  SIMCAT  OPFOR  position  should  not  be  required  to  communicate  with 
anyone  to  request  indirect  fire  support  It  is  proposed  that  the  same  procedure  followed  by  the 
controiler/trainer  to  process  a  friendly  force  indirect  fire  request  be  used  by  the  OPFOR.  That  is,  he  should  be 
able  to  input  the  appropriate  indirect  fire  data  (e.g„  coordinates,  direction)  directly  into  SIMCAT  using  the 
same  simple,  expedient  means  used  by  the  controiler/trainer  for  friendly  force  fire  requests.  In  addition,  as  was 
the  case  with  friendly  force  indirect  fire  requests,  SIMCAT  should  automatically  make  any  required 
adjustments  following  an  initial  call  for  fire  request 


Indirect  Fire  Delivery 

Once  the  SIMCAT  system  has  received  an  indirect  fire  request  (from  either  the  controiler/trainer  or 
OPFOR),  it  must  process  the  request  Specifically,  these  functional  requirements  involve  the  following; 

•  Determining  the  eventual  impact  area  of  the  requested  fire  in  relation  to  the  locations  of  all  OPFOR 
and  friendly  force  vehicles. 

•  Given  the  aforementioned,  determining  which  of  the  OPFOR  and  friendly  force  vehicles  should  be 
provided  with  auditory  and/or  visual  cues. 

•  Appropriate  timing  of  the  events  associated  with  an  indirect  fire  request  (i.e.,  time  from  request  to  shot, 
time  from  shot  to  splash). 

•  Providing  the  indirect  fire  requester  (i.e.,  controiler/trainer  or  OPFOR)  with  both  “Shot”  and  “Splash” 
messages  at  the  appropriate  times. 
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•  Maintaining  a  count  of  tbe  number  of  rounds  (by  fuze  type)  expended  and  remaining  (for  each  force) 
and,  when  allocations  have  been  expended,  informing  requester  (Le^  OPFOR  and  controller/trainer) 
accordingly. 

•  Providing  the  appropriate  visual  and  auditory  cues  (discussed  in  detail  in  the  next  section). 

•  Assessing  the  effects,  if  any,  on  targets  located  in  the  impact  area  and  providing  appropriate  cues 
accordingly. 

Representation  Requirements 

As  stated  previously,  once  S1MCAT  has  determined  where  indirect  fire  should  impact  and  has  determined 
who  or  what  can  detect  the  impacting  fire,  SIMCAT  must  represent  the  appropriate  cues  to  certain  SIMCAT 
positions.  To  determine  who  can  detea  the  impacting  fire,  the  following  factors  must  be  considered: 

•  Line  of  sight,  which  involves  terrain  relief  and  vegetation,  as  well  as  presence  and  degree  of  any 
obscurants. 

•  Range  from  impacting  fire  to  possible  detector. 

•  Number  of  batteries  fired  (Le^  number  of  rounds  impacting). 

•  Fuze  types  (including  smoke). 

•  Sheath  or  pattern  in  which  tbe  indirect  fire  is  impacting  (for  purposes  of  SIMCAT,  it  will  be  assumed  a 
normal  sheath  is  always  used). 

These  detection  criteria  will  differ  to  some  degree  depending  upon  whether  a  visual  or  an  auditory  cue 
requirement  is  being  considered  by  SIMCAT.  For  example,  if  a  tank  (in  a  defensive  position  with  its  engine  off) 
is  on  one  side  of  a  hill,  and  artillery  impacts  on  tbe  other  side,  there  is  no  question  that  a  visual  cue  would  g^t 
be  appropriate.  However,  it  can  also  be  concluded  that  the  occupantfs)  of  that  tank  should  be  provided  with 
some  form  of  auditory  cue. 

Impacting  fire  may  result  in  a  requirement  for  SIMCAT  to  represent  either  a  visual  or  auditory  cue,  or 
possibly  both,  to  SIMCAT  positions.  The  criteria  regarding  what  would  be  represented  should  consider  the 
same  factors  discussed  in  detail  in  the  section  on  the  SIMCAT  detection/identification  functional  requirements. 
These  criteria  differentiate  between  detection  and  identification;  although  a  visual  or  auditory  impacting  fire  cue 
may  be  detectable,  its  identification  is  dependent  upon  other  variables  (primarily  range).  As  a  result,  there  may 
be  a  requirement  for  several  impacting  fire  auditory  and  visual  cues.  For  example,  fire  impacting  200  meters 
away  would  sound  different  from  fire  impacting  2,000  meters  away,  and  both  would  look  different 


COMMUNICATION 

The  communication  functional  requirements  for  SIMCAT  serve  three  primary  purposes.  First  they  will 
permit  the  controller/trainer  to  interact  with  other  SIMCAT  positions  in  order  to  control  the  simulation. 
Second,  they  will  permit  the  controller/trainer  to  monitor  tactically  related  communications  for  evaluation  and 
feedback  purposes.  Third,  they  will  provide  SIMCAT  trainees  with  a  realistic  tactical  communications 
environment  Realism  in  this  context  means  that  the  communication  networks,  the  participants  in  those 
networks  (ut,  SIMCAT  positions  and  roles  simulated  by  SIMCAT),  and  the  means  of  communicating  found  in 
field  tactical  environments  will  be  represented  in  SIMCAT.  Communication  functional  requirements  are 
divided  into  five  different  areas:  (1)  Communication  Network  Participants,  (2)  Communication  Networks,  (3) 
Communication  Network  Selection,  (4)  Hand  and  Arm  Signals,  and  (5)  Jamming. 


Communication  Network  Participants 


To  understand  the  communication  requirements  for  SIMCAT,  it  is  first  necessary  to  know  what  positions 
or  roles  will  be  communicating  in  each  network  as  well  as  who  or  what  will  be  assuming  these  roles.  There  are 
seven  positions  or  participants  involved  in  the  communication  networks  required  by  SIMCAT.  It  should  be 
noted  that  all  seven  of  these  participants  will  never  be  involved  together  in  any  single  SIMCAT  communication 
network  (this  will  be  explained  in  greater  detail  in  the  next  section).  Specifically,  the  participants  involved  and 
whoever  or  whatever  will  assume  these  participatory  roles  are  as  follows: 

•  Trainees  —  These  include  the  platoon  leader,  platoon  sergeant,  TCI,  and  TC2.  The  communciadon 
requirements  of  these  individuals  will  be  restricted  to  those  normally  associated  with  their  positions  in  a 
tactical  situation. 

•  Controller/Trainer  —  The  controller/trainer  will  have  the  ability  to  communicate  with  all  trainees 
(individually  and  collectively)  as  well  as  with  the  individual  occupying  the  OPFOR  position.  The 
purpose  of  these  communications  is  to  control  the  simulation,  provide  feedback,  and  monitor 
communication  activity. 

•  OPFOR  —  The  individual  playing  the  role  of  the  OPFOR  must  be  provided  with  a  means  of 
communicating  with  the  controller/ trainer.  Most  of  these  communications  will  be  related  to  simulation 
control. 

•  Tank  Driver  —  The  tank  driver  of  concern  here  is  the  driver  of  the  tank  controlled  by  each  trainee,  but 
not  the  driver  of  any  tank  controlled  by  the  OPFOR.  The  driver  of  a  trainee-controlled  tank  will  be  a 
simulated,  computer-controlled  role  capable  of  recognizing  TC  driving  commands  (related  to  direction 
and  rate  of  movement)  and  able  to  produce  minimal  voice  outputs.  Specific  requirements  of  this  role 
are  addressed  in  detail  in  the  section  on  the  movement  functional  requirements  for  SIMCAT 

•  Gunner/Loader  —  The  gunner/loader  of  concern  here  is  the  gunner/loader  of  the  tank  controlled  by 
each  trainee,  but  not  the  gunner/loader  of  any  tank  controlled  by  the  OPFOR.  The  gunner/loader  of  a 
trainee-controlled  tank  will  be  a  simulated,  computer-controlled  role  capable  of  recognizing  firing 
commands  and  able  to  produce  minimal  voice  outputs  (i.e.,  '‘Identified”  and  "Up”).  Specific  voice 
input/output  requirements  are  addressed  in  detail  in  the  discussion  of  the  engagement  functional 
requirements  for  SIMCAT. 

•  FIST  FO  —  The  role  of  the  FIST  FO  will  be  assumed  by  the  controller/trainer  in  the  required 
communication  network.  The  function  of  this  role  will  be  to  receive  and  process  indirect  fire  requests 
from  the  friendly  force  platoon  leader  and/or  platoon  sergeant. 

•  Company  Team  Leader  —  The  role  of  the  friendly  force  company  team  leader  will  be  assumed  by  the 
controller/trainer.  Tile  function  of  this  role  will  be  to  provide  normal  company  team  leader 
communications  to  the  friendly  force  platoon  leader  and/or  platoon  sergeant 


Communication  Networks 

For  the  purpose  of  this  discussion,  communication  networks  or  nets  will  be  discussed  in  terms  of  the 
participants  who  are  to  be  provided  with  a  capability  to  communicate  with  one  another  on  the  net  and  the 
purpose  that  the  net  is  intended  to  serve.  SIMCAT  requires  four  communication  nets:  Platoon,  Company 
Team,  Tank  Intercom  (four  each),  and  controller.  Because  four  independent  and  separate  tank  intercom  nets 
are  involved,  SIMCAT  can  be  thought  of  as  requiring  seven  communication  nets  (especially  from  a  system 
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development  view).  However,  each  of  the  four  tank  intercom  nets  are  functionally  identical  Therefore,  these 
nets  will  be  regarded  as  one. 

The  purposes  of  the  four  main  communication  nets  are  as  follows: 

•  Platoon  —  Tactical  operations  net  used  by  all  members  of  tank  platoon  (i.e.,  trainees)  for  C3  functions. 

•  Company  Team  —  Tactical  operations  net  enabling  commundadons  between  all  vehicles  of  the 
company  team.  The  primary  purpose  of  this  net  for  SIMCAT  is  to  enable  the  controller/trainer  to  role 
play  a  company  team  leader  and  FIST  FO,  thus  providing  the  necessary  interface  in  these  roles  with  the 
platoon  leader  and/or  platoon  sergeant 

•  Tank  Intercom  —  Involves  satisfying  communication  requirements  among  each  tank  driver, 
gunoer/loader,  and  TC.  The  primary  purpose  of  this  net  in  SIMCAT  is  control  of  movement  and  fire. 

•  Controller  —  Used  solely  for  simulation  control  purposes,  this  net  permits  communications  between  the 
controller/  trainer  and  OPFOR. 

Table  3  provides  the  specifications  for  each  of  the  required  SIMCAT  communication  nets.  The  first 
column  specifies  the  communication  net  (as  described  above).  The  second  column  identifies  the  net  participants 
(described  earlier).  It  should  be  noted  that  a  net  participant  can  be  either  an  individual  occupying  a  SIMCAT 
position  (i.e.,  trainee,  controller/trainer,  OPFOR),  a  role  played  or  assumed  by  the  controller/trainer,  or  a 
computer-controlled  role.  All  participants  will  be  permitted  to  transmit,  receive/monitor,  or  both  transmit  and 
receive/monitor. 


Table  3 

SIMCAT  Communication  Network  Requirements 


Communication  Network 


Platoon’ 


Company  Team 


Tank  Intercom3 
(Each  Trainee  Tank) 


Controller 


Network  Participants 


Platoon  Leader2 
Platoon  Sergeant2 
TCI  and  TC2 
Controller/Trainer 

Platoon  Leader2 
Platoon  Sergeant2 
Controller/Trainer 

FIST  FO  (role-played  by  controller/trainer) 

Company  Team  Leader  (role-played  by  controller/trainer 

TC  (i.e.,  platoon  leader,  platoon  sergeant,  TCI  and  TC2) 
Gunner/Loader  (computer-controlled  voice  I/O) 

Driver  (computer-controlled  voice  I/O) 

OPFOR 

Controller/Trainer 


■.  -■  -•  -■  v  ■ 


'In  SIMCAT,  this  net  will  be  used  to  simulate  both  ths  radio  Platoon  Net  and  the  Hot  loop  or  wire 
communication  network  used  whan  the  friendly  platoon  la  in  defenae  positions. 

’The  Platoon  Loader  and  Platoon  Sergeant  trainee  positions  must  be  capable  of  monitoring  the  Platoon  and 
Company  Team  Nets  simultaneously.  However,  they  should  be  able  to  transmit  on  only  one  net  at  any  given  time. 
’Pour  tank  intercom  nets  (one  for  each  tank)  are  required.  Each  of  these  nets  must  be  independent  of  the  other. 
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Communication  Net  Selection 


The  controller/ trainer,  platoon  leader,  and  platoon  sergeant  positions  in  SIMCAT  will  have  the  capability 
to  access  several  different  communication  nets  (see  Table  3).  Therefore,  each  of  these  individuals  must  be 
provided  with  a  means  of  selecting  the  communication  net  in  which  he  wishes  to  transmit  and/or 
receive/monitor. 

The  platoon  leader  and  platoon  sergeant  must  be  able  to  select  and  then  access  one  of  three  SIMCAT  nets: 
Platoon  Net,  Company  Team  Net,  and  their  individual  Tank  Intercom  Net  Specifically,  their  communication 
net  selection  requirements  dictate  that  they  have  the  capability  to: 

•  Simultaneously  monitor  both  the  Company  Team  and  Platoon  Nets. 

•  Select  one  of  three  communication  networks  on  which  to  transmit — Tank  Intercom,  Platoon,  or 
Company  Team.  They  should  not  be  permitted  to  transmit  on  more  than  one  net  at  any  given  time. 

Each  TC  must  be  capable  of  selecting  and  then  transmitting  and  receiving  on  one  of  two  nets:  Platoon  Net 
or  Tank  Intercom  Net.  Specifically,  each  TC  must  be  capable  of: 

•  Selecting  either  the  Tank  Intercom  Net  or  Platoon  Net  to  monitor. 

•  Transmitting  on  either  net,  but  not  simultaneously  on  both. 

The  controller/trainer  net  selection  requirements  dictate  that  SIMCAT  provide  the  controller/trainer  with 
the  capability  to: 

•  Monitor  the  Platoon  Net  and  Company  Team  Net 

•  Simultaneously  monitor  die  Platoon  Net,  Company  Team  Net,  and  Controller  Net 

•  Transmit  to  each  trainee  position  simultaneously  over  the  Platoon  Net 

•  Select  any  one  of  three  SIMCAT  communication  networks  on  which  to  transmit  Platoon  Net 
Company  Team  Net,  or  Controller  Net 

Hand  and  Ann  Signals 

When  tank  platoons  are  involved  in  offensive  operations,  hand  and  arm  signals  are  often  used  for  tank 
platoon  communications.  Although  they  may  occur  less  frequently,  they  are  also  used  by  tank  platoons  in 
defensive  operations.  Given  their  frequency  and  the  ever  present  need  for  secure  communication  networks,  it  is 
imperative  that  SIMCAT  permit  and  facilitate  the  use  of  hand  and  arm  signals.  Specifically,  SIMCAT  must 
provide  each  of  the  trainee  positions  with  the  ability  to: 

•  Choose  from  10  to  20  hand  and  arm  signals  he  wishes  to  send. 

•  Send  a  selected  hand  and  arm  signal 

•  Select  the  recipient  (there  may  be  more  than  one)  of  a  hand  and  arm  signal. 

•  Receive  hand  and  arm  signals. 

•  Recognize  or  determine  from  whom  the  hand  and  arm  signal  is  coming. 

•  Witness  or  observe  hand  and  arm  signals  being  passed  between  two  tanks  other  than  his  own. 


The  specific  hand  and  arm  signals  to  be  incorporated  in  SIMCAT  have  yet  to  be  determined;  they  will  vary 
depending  upon  the  reference  source  used.  However,  it  is  known  that  there  will  be  a  minimum  of  10  and  a 
maximum  of  20  involved. 


Electronic  Warfare  (EW)  is  a  very  real  threat  on  the  modern  battlefield  and  will  be  experienced  at  all 
Army  echelons  in  combat  Therefore,  jamming  of  SIMCAT  communication  networks  must  be  considered.  As 
currently  envisioned,  SIMCATs  jamming  functional  requirements  will  involve  the  following: 


•  All  jamming  will  be  controlled  by  the  controller/trainer. 

•  The  controller/trainer  must  be  provided  with  the  ability  to  select  the  SIMCAT  communication  network 
to  be  jammed  (selection  alternatives  would  be  restricted  to  the  Platoon  and  Company  Team  Nets). 

•  The  controller/trainer  must  have  the  ability  both  to  initiate  and  terminate  the  jamming  of  a  net 

•  Although  jamming  can  manifest  itself  on  a  radio  net  in  a  variety  of  ways  (e.g.,  gulls,  random  noise, 
wobbler,  stepped  tones),  SIMCAT  will  be  required  to  simulate  only  one  manifestation. 


RESOURCES  AUDIT 

More  often  than  not,  events  on  a  battlefield  are  a  function  of  the  resources  (e.g.,  weapons,  food,  fuel) 
available  to  the  combatants  involved.  These  resources  are  not  inexhaustable  and,  once  expended,  can  change 
the  course  of  a  battle.  The  resources  of  concern  to  a  military  leader  vary,  depending  primarily  on  variables  such 
as  time  and  distances  involved.  For  example,  a  division  commander  would  have  to  concern  himself  about  food 
in  a  major  operation  involving  several  days.  A  platoon  leader,  on  the  other  hand,  would  not  concern  himself 
about  food  given  a  movement  to  contact  or  hasty  attack  mission  involving  short  distances  and  short  duration. 
However,  both  the  division  commander  and  platoon  leaders,  in  the  examples  given,  would  be  concerned  about 
other  resources,  such  as  munitions. 

SIMCAT  must  be  sensitive  to  resources  critical  to  the  scenarios  it  will  simulate.  This  sensitivity  is 
imperative  if  negative  training  is  to  be  avoided.  For  example,  if  a  single  Ml  Abrams  tank  is  permitted  to  fire  SO 
HEAT  rounds  in  a  SIMCAT  simulation  (which  far  exceeds  its  basic  load  of  HEAT),  negative  training  would 
be  likely  to  result  Therefore,  SIMCAT  must  maintain  an  audit  of  friendly  force  and  OPFOR  resources  (i.e., 
what  they  started  with,  what  has  been  expended,  what  remains,  and  when  a  resource  has  been  exhausted). 

An  inventory  of  possible  military  resources  would  be  an  ambitious  undertaking  to  develop  as  well  as  to 
reflect  in  the  design  of  SIMCAT.  However,  as  stated  previously,  the  resources  about  which  one  should  be 
concerned  vary  depending  on  the  nature  of  the  military  mission  (e.g.,  duration,  distances)  under  question.  In 
SIMCAT,  the  focus  will  be  on  armor  platoon  missions  or  operations  involving  relatively  short  periods  of  time 
and  short  traveling  distances  (e.g.,  10  to  40  kilometers).  Therefore,  only  munitions  (i.e.,  basic  loads  and 
expenditures  of  weapon  systems  involved)  and  fuel  resources  (i.e.,  fuel  capacities  and  fuel  consumption  rates  of 
vehicles  involved)  will  be  of  concern.  Each  of  these  resources  and  their  resource  audit  functional  requirements 
will  be  discussed  individually. 


Fud  Resource  Audit  Requirements 


SIMCAT  should  maintain  an  audit  of  the  amount  of  fuel  used  per  unit  of  distance  traveled  and/or  per 
unit  of  time  while  idling;  though  a  Ml  consumes  approximately  an  equal  amount  of  fuel  whether  moving  or 


idling,  this  may  not  be  true  for  other  vehicles.  This  requirement  can  be  expressed  in  terms  of  a  2  X  N  table 
where  N  equals  the  number  of  distinct  types  of  fuel  users  (e.g.,  Ml,  T72,  BMP).  The  first  entry  for  each  fuel 
user  type  represents  the  fuel  consumption  for  a  given  unit  of  distance  traveled.  Fuel  consumption  rates  (while 
vehicle  is  moving)  can  be  held  constant  regardless  of  such  things  as  movement  rate,  relief  and  other  factors 
which  have  only  a  marginally  different  effect  on  fuel  consumption.  The  second  entry  for  each  fuel  user  type 
represents  the  fuel  consumption  for  a  given  unit  of  time  while  idling.  Of  course,  fuel  consumption  rates  while 
idling  will  be  held  constant. 

Although  fuel  resource  audit  functional  requirements  are  critical  to  SIMCAT,  accurate  modeling  of  fuel 
consumption  rules  does  not  appear  to  be  sufficiently  important  to  warrant  extensive  development  effort  It 
appears  sufficient  that  fuel  consumption  be  computed  at  an  approximate  level.  However,  the  controller/trainer 
should  have  the  ability  to  provide  for  low  fuel  level  conditions  for  various  vehicles  if  he  chooses  to  initiate  a 
simulation  at  less  than  optimal  conditions. 

In  summary,  SIMCAT  must  maintain  a  fuel  resource  audit  for  each  vehicle  involved  in  a  given  simulation. 
This  dictates  that  SIMCAT: 

•  Be  aware  of  the  fuel  level  of  each  vehicle  when  simulation  is  initiated. 

•  Audit  the  movement  of  each  vehicle  and  time  spent  idling  in  terms  of  the  amount  of  fuel  expended. 

•  Inform  the  controller/trainer,  appropriate  trainee,  or  OPFOR  when  a  vehicle  has  exhausted  its  fuel 
supply. 

•  Provide  a  record  at  the  conclusion  of  a  simulation  reflecting  the  amount  of  fuel  consumed  and  the 
amount  remaining  for  each  vehicle  in  the  simulation  (necessary  to  provide  feedback  at  the  conclusion  of 
a  simulation). 

Munition  Resource  Audit  Requirements 

In  the  discussion  of  the  engagement  functional  requirements  for  SIMCAT,  all  weapon  systems  inherent  in 
SIMCAT  and  their  associated  basic  loads  were  specified.  Given  that  each  weapon  system  involved  in  a 
SIMCAT  scenario  will  have  been  identified  during  initialization  and  that  SIMCAT  possesses  a  resident  record 
of  the  basic  load  for  each  weapon  system  (or  a  decreased  basic  load  based  on  controller/trainer  modifications 
made  during  initialization  of  a  simulation),  SIMCAT  wfil  be  required  to: 

•  Maintain  an  audit  of  the  munition  expenditures  of  each  weapon  system  (i.e.,  rounds  fired  and  rounds 
remaining). 

•  Inform  the  controller/trainer  and  appropriate  trainee  or  OPFOR  when  a  weapon  system  has  exhausted 
a  class  of  munitions  (e.g.,  when  all  HEAT  rounds  in  TCl’s  tank  have  been  exhausted). 

•  Provide  a  record  at  the  conclusion  of  a  simulation  reflecting  the  amount  and,  if  appropriate,  type  of 
munitions  expended  and  remaining  for  each  weapon  system  in  simulation  (this  information  is  critical  to 
adequate  trainee  feedback). 

TIME 

As  a  battle  simulation,  one  of  the  most  critical  functional  requirements  of  SIMCAT  is  the  representation 
of  time.  Two  types  of  time  must  be  represented:  real  time  and  simulation  time.  Each  of  these  will  be  defined 
and  discussed  separately;  information  regarding  the  functional  requirements  related  to  simulation  time  will  then 
follow. 


Real  tune  refers  to  the  passing  of  time  in  the  “real  world”  environment.  It  is  continuous  and  cannot  be 
controlled.  It  can  be  represented  by  a  dock  on  the  wall  and,  in  terms  of  this  discussion,  it  is  external  to 
SIMCAT.  Real  time  relates  solely  to  “real  world  considerations;  in  the  case  of  SIMCAT,  these  considerations 
related  to  such  things  as  when  to  be  off  the  simulator,  when  to  break  for  lunch,  or  how  long  it  takes  to 
complete  a  single  SIMCAT  scenario. 

Simulation  time,  on  the  other  hand,  refers  to  the  passage  of  time  represented  in  SIMCAPs  simulated 
tactical  environment  This  passage  of  time  is  a  critical  factor  to  the  combatants  (i.e.,  OPFOR  and  trainees) 
involved  in  the  tactical  situation.  In  such  an  environment  time  is  an  important  cue  to  the  existence  or 
nonexistence  of  an  expected  event  For  example,  given  a  request  for  indirect  fire,  the  requestor  expects  certain 
events  at  certain  times,  such  as  a  shot  and  splash  message  as  well  as  the  artillery  actually  impacting.  Another 
example  would  be  the  expectation  of  a  platoon  leader  that  the  tanks  in  his  platoon  will  simultaneously  begin 
some  activity  at  a  specific  time  Given  that  the  controller/ trainer  controls  simulation  time,  OPFOR  and 
trainees  can  easily  lose  track  of  time.  For  example,  if  they  expect  artillery  to  impact  in  two  minutes  and  the 
controller/trainer  stops  the  simulation  for  five  minutes  and  then  begins  it  again,  from  their  perspective,  did  the 
artillery  impact  three  minutes  ago  or  will  it  impact  in  two  minutes? 

Given  that  SIMCAT  must  provide  all  simulation  positions  (Le^  trainees,  OPFOR,  and  controller/  trainer) 
with  some  perception  of  the  passage  of  time  within  the  tactical  environment  being  simulated,  certain  SIMCAT 
simulation  time  functional  requirements  have  been  identified. 


Simulation  Time  Requirements 

The  primary  purpose  of  SIMCAT  is  to  serve  as  an  armor  platoon  tactical  training  vehicle.  As  such, 
SIMCAT  must  permit  the  trainer  (or  in  this  context,  the  controller/trainer)  to  stop  a  simulation  at  any  point 
for  training  purposes  (e.g.,  to  point  out  an  error  mule  by  a  trainee)  and/or  for  administrative  purposes  (e.g.,  to 
break  for  lunch).  In  addition,  the  controller/trainer  must  have  the  ability  to  replay  all  or  a  portion  of  a 
SIMCAT  simulation.  Normally,  this  will  be  done  at  tire  conclusion  of  a  simulation  to  show  SIMCAT 
participants  what  occurred  and  to  permit  the  controller/trainer  to  review  the  just-completed  simulation  in 
order  to  determine  what  feedback  should  be  provided  to  the  trainees. 

To  satisfy  these  training-related  processes,  there  are  several  time-control  functional  requirements  SIMCAT 
must  satisfy.  Specifically,  the  controller/trainer  must  be  capable  of: 

•  Specifying  a  specific  simulation  time  he  wishes  to  recall 

•  Having  accessed  a  specific  simulation  time  (i.e„  a  point  in  a  just-completed  simulation  where  the 
location  of  all  friendly  and  OPFOR  vehicles  are  shown),  accelerating  or  slowing  down  (i.e., 
decelerating)  the  replay  of  the  simulation  events  (either  forward  or  backward  in  time). 

•  Stopping  or  freezing  in  place  an  in-process  simulation  or  replay  of  a  just-completed  simulation. 

•  Determining  the  simulation  time  (as  defined  previously)  in  either  an  in-progress  simulation  or  a  replay 
of  a  just-completed  simulation. 

While  a  simulation  is  in  progress,  SIMCAT  must  allow  the  controller/trainer  to  note  simulation  times 
related  to  critical  events  or  conditions  that  he  may  want  to  recall  at  the  conclusion  of  the  simulation.  This 
capability  will  provide  the  controller/trainer  an  easy  and  expedient  means  of  noting  points  in  the  simulation 
(which  may  prove  critical  to  feedback)  without  disrupting  the  flow  and,  therefore,  the  fidelity  of  the  simulation. 
Given  this  capability,  the  controller/trainer  can  review  a  portion  of  the  just-completed  simulation  not  only  in 
the  context  of  what  occurred  before  the  critical  incident,  but  in  the  context  of  events/conditions  that  occurred 
afterwards.  The  events/conditions  that  occurred  following  a  critical  point  notation  made  during  the  simulation 


may  render  invalid  the  concerns  that  'V  controller/ trainer  may  have  had  at  the  time  he  made  the  time 
notation.  This  critical  feature  of  SIMCa.  should  discourage  the  controller/trainer  from  stopping  an  in¬ 
progress  simulation  and  thereby  disrupting  its  flow  and  fidelity.  Such  a  situation  could  occur,  for  example,  if  a 
controller/trainer  were  to  stop  an  in-progress  simulation  to  point  out  that  there  were  no  tanks  in  overwatch 
only  to  find  out,  that  in  fact,  there  were,  and  that  he  had  overlooked  that  detail 


Time  Representation  Requirements 

Simulation  time  can  be  presented  using  an  analog  device  (e.g.,  clock  or  watch  with  hands)  or  a  digital 
device  (e^,  dock  or  watch  with  displayed  numbers).  While  either  approach  can  be  used  to  represent  time  to 
the  S1MCAT  participants,  the  participants  must  be  made  aware  of  the  following; 

•  The  starting  of  time.  Participants  must  be  made  aware  that  simulation  time  has  started  (or  restarted  in 
Use  event  that  simulation  time  has  been  stopped  by  the  controller/trainer). 

•  The  passage  of  time.  Participants  must  be  provided  the  simulation  time  and  be  made  aware  that 
simulation  time  is  passing.  SIMCAT  must  be  capable  of  presenting  simulation  time  to  the  participants 
at  normal,  accetersted,  or  decelerated  rates. 

•  The  stopping  of  time.  Participants  must  be  made  aware  that  simulation  time  has  been  stopped 
whenever  the  controller/trainer  decides  to  stop  it 

•  The  resetting  of  time.  If  the  controller/trainer  decides  to  reset  simulation  time  to  an  earlier  or  later 
point  the  participants  must  be  made  aware  of  this  fact  and  must  be  shown  the  point  at  which  the  time 
has  been  reset. 


POST-SIMULATION 

SIMCAT  differs  from  a  highly  structured  procedural  or  part-task  trainer  having  predetermined  conditions, 
actions  and  standards.  Instead,  SIMCAT  is  a  tactical  trainer  in  which  only  the  initial  conditions  are  set  (i.e., 
terrain,  TO&E  of  two  opposing  forces,  and  conflicting  missions).  As  a  result,  a  multitude  of  events,  actions, 
and  conditions  will  occur  at  a  very  rapid  rate  during  the  course  of  any  single  SIMCAT  simulation.  Added  to 
this  is  the  fact  that  the  conditions,  events,  actions  and  outcomes  of  each  scenario  simulated  in  SIMCAT  will  be 
unique,  making  the  problem  of  “what”  feedback  to  provide  and  “how”  to  provide  it  a  serious  issue.  These 
conditions  dictate  that  SIMCAT  must  provide  the  controller/trainer  access  to  various  data  in  various  forms 
(e.g.,  visual,  audio,  hard  copy)  from  which  he  can  determine  what  feedback  to  provide  the  trainees  and  how  to 
provide  it  The  requirements  associated  with  providing  feedback  have  been  labeled  post-simulation  functional 
requirements. 

Post-simulation  functional  requirements  are  defined  as  the  SIMCAT  processes  necessary  to  support  the 
controller/trainer  responsibility  to  provide  feedback  to  trainees.  Post-simulation  functional  requirements  foil 
into  three  categories:  visual  playback,  audio  or  communications  playback,  and  hard  copy  outputs. 


Visual  Playback  Requirements 


One  critical  aspect  of  providing  feedback  related  to  tactical  environments  is  the  ability  to  reconstruct 
events,  actions,  or  conditions.  In  SIMCAT,  each  of  the  positions  involved  will  be  provided  a  different 


perspective  of  events  as  they  occur.  In  addition,  as  the  information  processing  capabilities  of  each  position 
become  overloaded  during  a  simulation,  the  ability  of  the  trainee  to  recall  events,  conditions,  or  actions 
accurately  will  be  severely  limited.  Therefore,  SIMCAT  must  have  the  capability  to  record  events,  conditions, 
and  actions  as  they  occur  with  total  accuracy.  This  recall  requirement  of  SIMCAT,  coupled  with  the  need  to 
reconstruct  events,  conditions,  and  actions,  has  resulted  in  the  identification  of  the  following  visual  playback 
functional  requirements: 

•  The  controller /trainer  must  be  able  to  specify  a  simulation  time  in  hours  and  minutes  (e.g.,  1  hour,  31 
minutes  or  1 1 13  hours)  and  have  SIMCAT  recall  the  situation  at  that  point  in  time  in  a  just-completed 
or  temporarily  halted  simulation. 

•  Given  a  simulation  time,  the  controller/trainer  must  be  able  to  specify  which  perspective  he  wishes  to 
see  (Len  whatever  was  seen  on  the  display  of  the  controller/trainer,  OPFOR  or  any  one  of  the 
trainees). 

•  The  controller/trainer  must  be  able  to  display  perspectives  at  different  SIMCAT  positions 
simultaneously.  Suppose,  for  example,  that  a  controller/ trainer  wishes  to  review  a  situation  in  which  a 
Ml  tank  was  destroyed  by  a  SAGGER.  To  reconstruct  this  event,  it  would  be  advantageous  to  display 
simultaneously  the  perspective  of  the  controller/trainer  (Le^  God’s-eye  view  of  all  vehicles  involved), 
the  OPFOR  (Le.,  what  the  OPFOR  saw  at  the  time),  and  the  trainee  whose  tank  was  destroyed. 
Accomplishing  this,  the  controller/trainer  can  review  the  situation  from  the  point  of  view  of  each 
participant  and  point  out  what  should  have  happened  (e.gM  “This  is  what  the  OPFOR  saw;  you  should 
have  detected  him,  and/or  bad  someone  in  overwatch  ). 

•  Given  a  simulation  time,  perspective,  and  station  selection,  the  controller/trainer  must  have  the  ability 
to  move  forward  or  backward  at  either  an  accelerated  or  a  decelerated  rate. 


Audio  or  Communicatioas  Playback  Requirements 

It  is  understood  that  SIMCAT  will  be,  among  other  things,  a  vehicle  for  training  command,  control,  and 
communication  in  a  tank  platoon.  Therefore,  it  is  important  that,  at  the  conclusion  of  a  simulation,  the 
controller/trainer  be  provided  the  ability  to  review  (prior  to  providing  feedback  to  trainees)  and  reconstruct 
(while  providing  feedback  to  trainees)  communications  which  occurred  during  the  just-completed  or 
temporarily  halted  simulation.  This  need  dictates  that  SIMCAT  record  any  communication(s)  that  occurred 
during  the  simulation  and  provide  the  controller/trainer  the  ability  to  access  and  recall  it  Given  these 
controller/trainer  feedback  requirements,  the  following  audio  or  communications  post-simulation  functional 
requirements  have  been  identified: 

•  The  controller/trainer  must  be  able  to  select  the  SIMCAT  communication  net  he  wishes  to  access  (i.e.. 
Controller  Net,  Company  Team  Net,  or  Platoon  Net,  defined  and  addressed  in  detail  in  the  discussion 
of  the  SIMCAT  Communication  Functional  Requirements). 

•  Having  selected  the  communication  net  he  wishes  to  access,  the  controller/trainer  must  be  able  to 
specify  the  simulation  time  (or  point  in  the  net’s  recording)  that  he  wishes  to  access  (e.g.,  1  hour,  31 
minutes).  SIMCAT  must  then  “turn  back  the  dock”  to  the  point  designated  by  the  controller/trainer 
on  the  communication  net  specified. 

•  Given  the  communication  net  and  simulation  time,  the  controller/trainer  must  be  provided  the  ability 
to  move  forward  or  backward  from  that  point,  and  to  hear  what  was  communicated.  He  must  be  able 
to  move  forward  or  backward  at  one  of  three  rates:  real  time,  accelerated  time,  or  decelerated  time.  It 
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should  be  noted  that  the  controller/ trainer  no  doubt  will  synchronize  visual  playbacks  with  audio  or 
communication  playbacks. 

•  Given  that  SIMCAT  will  have  more  than  one  communication  output  channel  (e.g.,  a  “squawk  box”  at 
the  controller/trainer  station,  one  for  each  trainee  position),  the  controller/trainer  must  be  able  to  select 
the  communication  output  channel  on  which  he  wishes  the  communications  to  be  played.  It  should 
also  be  anticipated  that  the  controller/trainer  may  desire  to  play  back  two  synchronized  communi¬ 
cation  nets  simultaneously. 


Hard  Copy  Output  Requirements 

Although  the  conditions,  events,  actions,  and  outcomes  of  each  scenario  simulated  in  SIMCAT  will  be 
unique,  it  can  be  anticipated  that  certain  data  may  be  critical  when  providing  feedback  to  the  trainees.  These 
data  requirements  can  be  viewed  as  serving  two  purposes.  First,  they  will  provide  the  controller/trainer  with 
clues  about  both  good  and  poor  performance.  As  such,  the  data  could  prompt  the  controller/trainer  to  look  for 
additional  information.  Suppose,  for  example,  that  SIMCAT  provided  the  controller/trainer  with  a  hard  copy 
output  outlining  when  (in  simulation  time)  each  friendly  vehicle  was  destroyed  or  damaged  and  which 
OPFOR  weapon  system  caused  the  destruction  or  damage.  The  controller/trainer  could  use  these  data  to 
identify  the  visual  and  audio  or  communication  points  (Le_,  simulation  time)  that  he  should  play  back  to 
determine  what  happened  and  what  feedback,  if  any,  should  be  provided.  The  predetermined  data  could  also 
be  used  in  output  form  as  direct  feedback  to  the  trainees,  thereby  providing  each  trainee  with  a  listing  of  the 
number,  type,  and  time  be  fired  main  gun  rounds  and  the  OPFOR  casualties,  if  any,  that  resulted. 

Identifying  and  specifying  post-simulation  hard  copy  output  requirements  for  SIMCAT  (Le^  content  and 
format)  normally  requires  several  analyses  (e.g.,  training  objectives,  possible  events)  and  a  sequential 
development  process.  Given  the  time  constraints  associated  with  the  development  of  SIMCATs  functional 
requirements,  however,  the  procedures  normally  followed  in  identifying  and  specifying  the  hard  copy  output 
requirements  cannot  be  executed.  Therefore,  the  SIMCAT  hard  copy  output  functional  requirements  presented 
here  should  be  considered  preliminary  and,  as  such,  subject  to  change. 

As  currently  envisioned,  the  post-simulation  bard  copy  outputs  for  SIMCAT  fall  into  three  categories: 
simulation  summary,  individual  weapon  system  summary,  and  indirect  fire  utilization  summary.  Each  of  these 
is  explained  below. 

•  Simulation  Summary  —  This  output  provides  a  complete  summary  of  a  completed  simulation.  It  is 
composed  of  four  parts:  general  information,  OPFOR  summary,  friendly  force  summary,  and  a 
chronological  list  of  losses.  The  general  information  part  of  this  output  contains  the  simulation  time 
(i.e.,  duration  of  the  simulated  scenario),  playing  time  (Le.,  actual  time  required  to  "play”  the 
simulation),  identification  and  date  of  the  scenario  played,  and  names  of  the  individuals  responsible  for 
each  of  the  SIMCAT  positions.  The  next  two  parts  provide  a  brief  summary  for  each  of  the  opposing 
forces  (i.e.,  OPFOR  and  friendly  force),  specifying  the  mission  of  each  force,  amount  of  indirect  fire 
allocated,  beginning  TO&Es,  and  losses  at  the  conclusion  of  the  simulation.  The  fourth  and  last  part  of 
this  output  contains  a  chronological  listing  of  losses.  Losses,  in  this  context,  are  defined  as  the 
destruction  or  damaging  of  either  an  OPFOR  or  friendly  force  vehicle.  Listed  in  the  sequence  they 
occurred,  each  loss  is  specified  in  terms  of  the  simulation  time  at  which  the  loss  occurred,  the  nature  of 
the  loss  (Le.,  OPFOR  or  friendly  force  vehicle,  type  of  vehicle,  and  which  vehicle,  e.g.,  PSG's  Tank), 
the  cause  of  the  loss  (indirect  fire  or,  if  the  result  of  a  direct  fire  weapon,  which  vehicle  caused  the 
casualty)  and  the  location  of  the  vehicle  when  it  was  lost  (its  grid  coordinate).  A  sample  of  this  output 
is  shown  in  Figure  1. 
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Figure  1:  SAMPLE  OUTPUT  OF  SIMULATION  SUMMARY 


•  Individual  Weapon  System  Summary  —  This  output  would  be  produced  for  each  of  the  weapon 
systems  involved  in  a  simulation.  Therefore,  for  a  Ml  tank,  two  different  Individual  Weapon  System 
Summaries  would  be  produced,  Le^  one  each  for  the  tank  main  gun  and  the  coax.  The  heading  of  this 
output  would  identify  the  weapon  system  being  summarized  (e*,  Platoon  Leader’s  Tank  Main  Gun 
Summary)  and,  in  parentheses,  the  name  of  the  individual  responsible  for  that  weapon  system  during 
the  simulation  (e*,  2LT  J.  K.  Ogus).  In  addition,  this  output  is  comprised  of  two  parts:  the  summary 
and  the  *«gfw»*w*  record.  In  the  summary  part,  the  type  and  number  of  rounds  that  the  weapon 
system  started  with  would  be  noted.  This  would  be  followed  by  identification  of  the  rounds  expended 
expressed  in  terms  of  both  a  percentage  and  number.  The  mean  range  at  which  targets  were  engaged 
with  the  weapon  system  would  then  be  exprewed  in  meters.  A  summary  of  the  effects  when  using  each 


type  of  round  would  then  be  shown.  This  summary  would  list  each  target  (e^,  BMP)  that  was  hit 
using  that  type  of  round  and  the  actual  effect  (e*.,  destroyed  or  damaged)  on  the  target  Finally,  a 
rounds  per  hit  ratio  would  be  computed  and  noted  (e.g.,  1.5  rounds  per  hit).  The  engagement  record 
portion  of  this  output  would  provide  a  chronological  listing  of  data  related  to  time  the  weapon 
being  summarized  was  fired.  Here  the  time  and  type  of  round  fired  (if  applicable)  as  well  as  the 
location  of  the  weapon  system  when  the  round  was  fired  (expressed  by  a  grid  coordinate),  the  type  of 
target  being  engaged,  range  of  target  (expressed  in  meters),  and  effect  (e.g^  missed,  destroyed),  if  any, 
would  be  noted.  The  last  entry  in  the  engagement  record  would  always  be  either  die  pbm,  location,  and 
what  caused  the  weapon  system  being  summarized  to  be  destroyed,  or  a  notation  that  the  weapon 
system  survived,  intact,  at  the  time  the  simulation  was  terminated.  A  sample  of  this  output  is  shown  in 
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Figure  2:  SAMPLE  OUTPUT  OF  INDIVIDUAL  WEAPON  SYSTEM  SUMMARY 


Indirect  Fire  Utilization  Summary  —  A  summary  of  indirect  fire  usage  would  be  produced  for  both  the 
OfrFOfe  and  friendly  forces.  This  output  would  be  composed  of  two  parts:  the  summary  and  the 
utilization  record.  In  the  summary  part,  a  summary  of  the  indirect  fire  allocated  (by  fuze  type  and 
number  of  rounds),  and  used  (in  terms  of  both  a  number  and  percentage)  would  be  provided  along 
with  their  effects  (expressed  in  terms  of  type  and  number  of  vehicles  destroyed  or  damaged),  including 


